Dynamic websites finally possible? My proposal, please critique

I was doing some research and it seems that we can already call daemon methods from JS.
More specifically, we can call PubSub methods and “name publish”.
Using those features I envisioned a dynamic site system like the ones on ZeroNet. Let me show you an example.
The site descriptor and static files:

  1. You create a new IPNS <id>, say <Example:id>;
  2. Under <Example:id> you put an index.html that bootstraps the applications and a JSon object, called “SITE_DESCRIPTOR”, with at least the following information:
        #Public key of the owner, used to sign "advertisement messages"
        #(mentioned somewhere below).
        owner_pubkey: <PubKey>,
        timestamp: "datetime_string",
        #Directory with the site's static resources: html, css, js, etc.
        content: "\<cid\>", 
        #List of users and permissions.
        users: {
                   \<PubKey\>: {
                                #List of <PubKeys> this user wants to receive messages from.
                                #Other peers will not relay messages that have not been signed with
                                #one of those <PubKeys>. 
                                #This is not strictly necessary, but would reduce congestion. For it to 
                                #work the site application would need to be able to capture PubSub    
                                #messages to the site topic(in PubSub terminology).
                                following: [  ],

                                #Here is the user generated content. This could be a list of <cid>'s or an
                                #IPNS <id>. In the later case the user would keep a list of all the content
                                #she created on a json file under that <id>.
                                #This could be in plaintext (for public content) or encrypted with the 
                                #<PubKey>'s of the people that should be able to 
                                #see it (i.e., the user followers).
                                content: [  ],

                                #Here we have the user's permissions. Those are used by other nodes 
                                #to decide what content they receive from this user is valid.
                                #For example: if the user signs and publishes a post on someone else's
                                #name, nodes will come here to see if this is acceptable behavior.
                                #This could be used to implement moderation. Of course there is no way
                                #to force nodes to accept an "delete bad post" message from a mod.
                                #People would accept moderation from people they like.
                                permissions: {
                                             publish_with_usernames: ["user1", "admin", "mom"],
                                             moderator: true,

To create an account on the site, an user would fill a JSon object, called “USER_REGISTRATION_REQUEST”, and publish it with the PubSub mechanism. The object would be published to the topic <Example:id> (that is the site’s IPNS <id>).

When the owner of the site receives this object, she would check it’s validity and add the user’s <PubKey> on the “users” section of the SITE_DESCRIPTOR (the Json above). She would then republish the new SITE_DESCRIPTOR on the site’s IPNS <id>.

The USER_REGISTRATION_REQUEST would look like this:

signature: "user_signature",
payload: {
          timestamp: "datetime_sring",
         #The user could check if the desired username is available by looking at the
         #SITE_DESCRIPTOR. If there is a data race and someone register the desired handle
         #before her, this request fails silently. The application software running on the user's
         #browser would notice that the desired username was registered by a different
         #\<PubKey\> and show an error message.
         username: "peter_parker1337",
         #The user's public key. This will be added 
         pubkey: <PubKey>,
         method: "register_user"

The site has now been updated, and has a new user. But other nodes might not have received the PubSub message above (depending on the routing mechanism in place). To advertise that there are changes to everyone, the owner of the site would publish an advertisement to the PubSub mechanism, on the topic <Example:id>(the IPNS address). It would be called “UPDATE_ADVERTISEMENT” and would look like this:

    signature: "signature of the content below by the site owner",
    payload {
         timestamp: "datetime_string",
         method: "update_site_descriptor"

Users can publish content by filling a JSon object called “NEW_CONTENT” and publishing it with the PubSub mechanism with the IPNS <Example:id> of the site as the topic. Other nodes will check the validity of this object against their copies of the SITE_DESCRIPTOR and decide whether to accept it or not.
The NEW_CONTENT object would look like this:

    signature: "signature of the payload with the user <PubKey>",
    payload: {
         timestamp: "datetime_string",
         #Content entries, to be added or removed from the user's "content" member, on the
         #SITE_DESCRIPTOR object.
         content: [
                      #"add" or "rm"
                      method: "add", 
                      #The actual content. Could be a \<cid\> or the actual raw content. It could be
                      #in plain text(public) or there could be a copy encrypted with the public key
                      #of each of the user's followers (as described in the SITE_DESCRIPTOR).
                      data: {  },

It seems to me like it could work. It doesn’t need any code change, everything could be done by calling daemon methods, through the HTTP Api, from the application running within the browser(the site). It also does not seem to depend on IPNS itself, only on the PubSub mechanism, so it could work with other name systems too.

What is your opinion? Am I missing something?
Feel free to list possible vulnerabilities.

Thanks and sorry for being dumb and posting it too soon.

EDIT: Okay, it is finished now. Sorry for being dumb. I blame my parents.

I published it by accident by pressing Tab and Space in sequence. Please give me a few minutes to finish typing it.

This sort of thing is definitely possible― though I think it’s useful to note that OrbitDB’s a database using IPFS pubsub, and it looks like (?) the norm for making dynamic sites fully on the IPFS stack.

But as for the “website owner” thing… when it comes to distributed sites with users, I dunno if the concept of a site owner’s particularly useful, or that it’s good design to have the entire site by-default trusting a single user.

I mean you could totally do that, and it’s probably easy to get going and manage, but it feels like making an traditional centalized site with extra steps. You do get the transportation benefits at least, I guess.

On that topic, do you happen to know any site using it? I did some research before posting but could only find the examples on their github.

It is more of a moderation role, it is not enforceable the same way it is with a central server. Other nodes can always choose to ignore the decisions of the owner and accept anything they receive on the PubSub.
It is useful for the comment section of a blog, for example.

1 Like