Subnostr

I see why you want this.

I'm imagining a parallel-to-nostr protocol that is also over websockets, can deal with chunking (to handle the websocket frame size issue), is binary (to speed the transfer), handles compression (like HTTP, probably via HTTP actually), specifies commands to edit/update data, has some kind of auth but still uses nostr pubkeys. Something like WebDAV but way cleaner and designed for nostr identities.

I think the amount of work to do this would only be 20% more than trying to do it over nostr, because you wouldn't be duplicating very much of what nostr is, and a lot of code used for nostr could be repurposed.

Just an idea.

Vitor Pamplona 2y ago

I am not sure the benefits of a protocol aligned with the needs drastically outweigh the lack of network effects.

Every collaboration-centric software start up designs their own protocols in a similar way you described. Most of them fail, despite the massive capital investments they usually receive.

I think a better idea is to reuse a less-optimized protocol but with large network effects (and hopefully help build those network effects) to avoid being replaced by the next startup with millions in cash laying around.

It's like JavaScript. One of the worst languages ever invented. But one of the most used ones, nevertheless.

Reply to this note

Please Login to reply.

Discussion

faisal 2y ago

Wouldn’t it inherit nostr network effects If it was another protocol or sub-protocol designed for this purpose?

Vitor Pamplona 2y ago

Most Nostr micro apps that wonder too far for the sake of better engineering die off very quickly.