nostr-next and mosaic in relation to rostra

[mikedilger]

I'm a nostr developer (gossip client, chorus relay, NIP-65 and more) who has always been a bit frustrated with the chaos of nostr. I prefer standards and compatibility leading to a solid user experience. It has been a great place to experiment and people are building all kinds of wild things on it. But it has limitations and quirks and some things I'd like to do simply can't really be done without breaking it too much.

So I went off and started Mosaic https://github.com/mikedilger/mosaic-spec as a proposal for how I would rebuild it from scratch. I haven't finished that to a working set of libraries yet, although a lot of the coding has been done.

I've also discussed with many people inside the nostr community who have their ideas about what "nostr 2.0" ought to look like.

Nonetheless, my point is that looking around at all the other nostr-like things people are working on, I want to draw from and learn from them, and perhaps corroborate on a successor protocol to nostr.

My problems with nostr are included in the https://github.com/mikedilger/nostr-next repository but include big ones like that secp256k1 locks us out of a lot of good tech (TLS, pkarr/Iroh, etc), that it's kinda too late to have device keys and offline master keys, that the records are JSON (and the performance of parsing JSON is not good), that servers don't have identity keypairs, that we depend on DNS and CAs still, that we don't have detection of censorship (linking back to previous events), etc.

I very much want a base layer that does not specify much about how social media should work, but really just provides the core functionality to higher layers which make those decisions. That core being things like identity, record format, and protocol.

Rostra is close to what I'm aiming at, but different, and I'll have to dig to find out precisely what it does and doesn't do.

But it doesn't make sense for everybody to build their own social media system and then chat with themselves upon it. So it was time to contact you.

[dpc]

But it doesn't make sense for everybody to build their own social media system and then chat with themselves upon it. So it was time to contact you.

It doesn't make sense even for anybody. :D

I think that nobody (=tiny minority) cares about decentralized social media systems, and I wrote Rostra for fun and figuring out that my ideas are technically sound, not because I believe anyone will use it.

Moxie explained it very well: https://www.youtube.com/watch?v=DdM-XTRyC9c . In practice everything is worse and harder with decentralization, so decentralized systems tend to lose with centralized applications.

Some people use Nostr not due to technical aspects, but because Nostr got the right vibes that latched with a small but sustainable group of people that like to LARP about decentralization due to being Bitcoin adjacent, and shared interest where they can forever showcase a list of half-assed prototypes that are cool enough to generate buzz.

Anyway, always happy to discuss topics related to architecture and design of distributed social media. It's a fun topic to play with.

The core of the design is typically the same - self-generated cryptographic identities, signing their messages. I think the best place to start to understand Rostra is:

rostra/crates/rostra-core/src/event.rs

Line 96 in cf0a383

pub struct Event {

[mikedilger]

I'd say we have different opinions about decentralization. Moxie has reasons make decentralization sound hard. Nostr has mostly achieved it (except bootstrapping) and Mosaic will fix that.

Here is how it works:

1. You get a pubkey from somebody somehow. No reason to do social media if you don't know anybody.
2. Use the bittorrent Mainline DHT to lookup that pubkey's record to get the servers they are using.
3. You post to their inbox so they can see it. They post to their outbox so the world can see it. The inverse applies too for yourself.
4. Servers also register their endpoints in the bittorrent Mainline DHT and then they can switch endpoints or expose themselves to multiple networks (IPv4, IPv6, Tor).

Yes the bittorrent Mainline DHT needs onramps and there are only 3 or 4 public ones that still work. But there are thousands of servers and onramps that aren't advertised.

[dpc]

Nah. Moxie is right. People don't care about protocols, they care about applications and content. Implementing something that works is hard enough, but then expectations change from under you, and evolving decentralized ecosystem is again harder than centralized one. I have >20 years of experience watching this happening in things I enjoyed, starting probably with Jabber/XMPP. Social media, at least in the popular form like Facebook, Twitter, Instragram is all about content and network effects.

Anyway, for mainline etc. you can consider using Pkarr, just making sure you're aware of it.

[mikedilger]

I am aware of pkarr and have spoken with Nuhvi on it. I'm using his mainline library but not pkarr itself, which we argued out.

I'm also >20 years experience here, since Sun Microsystems and IETF days. Just so you don't think I'm some red-eyed spring chicken bitcoiner who naively believes everything is possible and doesn't understand the difficulties you mention.

I'm not expecting to compete with and beat centralized systems. They will always have the majority of people. It is not true that everybody has to be on the same system and for that system to have a significant network effect for the social media to be useful. I use nostr every day. Yes, I also use X. That is not a failure in my book.

But it is still the case that centralized systems repeatedly let us down. And I'm willing to put in a lot of work to avoid those let downs.

Moxie talks about decentralized protocols ossifying. It is true that once widely deployed you can't just make changes. But I'd say IPv4 has been wildly successful. It doesn't matter that it has ossified (in truth there have been a lot of changes to IPv4 since it started). And similarly a social media base layer doesn't need change in breaking ways if designed well enough. And if it doesn't try to own everything, the innovation can happen in higher layers, and giving up on a higher layer for a newer higher layer (as the higher layers ossify) doesn't throw everything out and start over, you still maintain a lot of core functionality.

But I've gotten the sense you are jaded and over it all so I won't bother you much further.