Subnostr

This recent update sets us up for the next stage of development: file versioning and collaborative tools.

While it's true that some interfaces already exist in Nostr that allow two users to collaborate with one another on the same "record", they mostly lack a way of controlling when to change the version of a regular full fat file, which they cannot do when the file is in a web server.

NIP 95 gives them the very, very early tools to set those systems up. By growing the amount of relays willing to support replaceable files in their system (current nip95 is non replaceable), we push the tooling needed for this larger visions.

Reply to this note

Please Login to reply.

Discussion

captain ☦️ 2y ago

🫡

iefan 🕊️ 2y ago

Your recent moves were very bold. I hope everything works out in the end and that all users get the best possible experience. 🍀

current 2y ago

Good one. Can you point me to some use cases for NIP-95? Still trying to wrap my head around it..

Vitor Pamplona 2y ago

nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m was just talking about GItHub. This is no nostr git without a version of NIP 95.

Vitor Pamplona 2y ago

* There is no nostr git

Mike Dilger ☑️ 2y ago

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.

Rimbaud 2y ago

Yes! This is the kind of idea. re: parallel development. -- I like this.

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.

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.