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:
- You create a new IPNS <id>, say <Example:id>;
- 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: { },
},
]
}
}
Conclusion:
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.