In-protocol extensibility

[elsirion]

Currently the validity and semantics of events is defined by protocol extensions which have to be implemented by all clients that want to support the new feature. What if instead event semantics were defined in-protocol as a special event type, let's call it an app manifest.

That app manifest would define:

• A validate function that is used to validate the schema of an event belonging to the app
• A aggregate function that receives all events belonging to the specific app and builds the app state from them using CRDT techniques. There might need to be a way to specify which subset of events belonging to the app to fetch (e.g. user looking at a NewTwitter account -> only fetch events related the user and belonging to the NewTwitter app).
• A render function that takes the aggregated state and turns it into some UI description language to be displayed to the user that also allows interaction.
• A create event function that can be called from the UI to interact with the app

These app manifests thus define everything required for any particular app on top of Nostr to work and clients would merely need to run WASM and display UIs defined using some description language. They'd be browsers instead of app-specific clients.

If the app manifest was updatable using a signed event (e.g. threshold-signed using FROST) then groups of people could keep iterating on their particular protocol extensions without having to bug tens of client devs to implement their newest NIP.

Some more resources:

• Similar idea on top of freenet https://github.com/freenet/locutus#how-does-it-work
• A blog article by me describing a similar concept https://sirion.io/posts/bitcoin-web3/

[dr-orlovsky]

Very interesting approach. I was thinking about something similar during my work on Bifrost - the generalization of the lightning network to support arbitrary future payment channel types without protocol changes. For that purpose, I was planning to use AluVM, but I agree that in the case of social network working in Web WASM would be a better option.

I am happy if eventually your idea can get into an NRP here.