This is the fourth recording in a series of recordings on Mosaic.

Today is the 12th of June, 2025. I'm Mike Dilger.

This recording is very important because it explains whether or not nostr can be organically
migrated towards certain ends, or whether nostr needs to be started over. Both branches of this
decision tree can be taken simultaneously. Mosaic represents starting over. But Nostr can
simultaneously attempt to achieve similar results.

First of all, starting over has massive downsides. All the current nostr applications would not
work with a restart. The current nostr identities might still be usable in a restart, but the
current events probably wouldn't be. And there remains the risk that the community may end up
forking on some level, or at best becoming somewhat disjoint, making it that much harder to achieve
a critical mass and network effect.

Given these huge downsides, there must be some pretty significant upsides. And there are two such
significant upsides.

But before I describe those upsides, I have to explain what it is, technically, that is motivating
this concept of "starting over".

Nostr uses the secp256k1 Koblitz elliptic curve cryptosystem with Schnorr signatures. This is the
same cryptosystem that bitcoin uses.

But this cryptosystem is not compatible with many things outside of bitcoin. For some examples:
such keys cannot be used to secure a TLS connection, cannot be used to sign records in the
BitTorrent Mainline DHT, cannot be used as ssh keys, cannot be used as wireguard keys, and cannot
be used in OpenPGP without using a special fork of OpenPGP.

So Mosaic proposes using the ed25519 cryptosystem which is compatible with all of those standards.

OK, let's look at the two upsides of switching identity over to ed25519:

First of all, consider the idea of every relay having it's own key pair. In this way, a single relay
could be available on multiple endpoints: Tor, IPv6, IPv4, or perhaps simultaneously in different
regions worldwide, and still be the same server with the same data and policies and reputation. In
such a situation, relays would advertise their endpoint lists in the same kind of way that users
advertise their relay lists, in digitally signed records. And furthermore, relay connections over
TLS could be authenticated by the relay's key pair. That is, Certification Authorities could become
irrelevant. Relays would use Raw Public Key or self-signed certificates, and clients would
authenticate them via the TLS connection by checking that they provably know the private key of the
public key that the client was intending to connect to. In this way, trust in DNS would no longer
be required either. If DNS was subverted, the wrong machine would not be able to establish a TLS
connection with the client because it wouldn't have the right private key.

Being able to dispense with the abusive trust relationships between users and Certification
Authorities, who they have little reason to trust, and between users and DNS services who they also
have little reason to trust, is I think the biggest benefit.

But there is a second upside having to do with bootstrapping.

For those who aren't familiar with the English phrase bootstrapping, it comes from an idiom "to
pull oneself up by one's bootstraps," something that is obviously impossible. You cannot lift
yourself up off of the ground by looping your fingers into your bootstraps and pulling. Yet
booting a computer seems very much like this. You start with very little, hardware that loads a
small sector from a fixed place on the disk and executes it. And with no additional external input,
everything else must follow.

Bootstrapping in nostr and Mosaic starts with just a public key. From that, you need to be able to
interact socially with the person that public key represents. How can we do this?

Well, we can break this into two parts:  first get the servers that the person uses, then get the
social media data from those servers.

A person can create a document that lists the servers that they use, and digitally sign it.

So the only problem remaining is: how do we find that first document?  We can't go look on the
servers that the person uses because we don't know which servers they use yet.

What nostr does is to have people save the document onto a bunch of popular relays and make other
people look around for it on the relays that they think are popular. But this requires people to
agree on which relays are popular, which is a centralizing force. Such a force creates a set of
crucial servers which then can be targeted and taken down to disable the entire system.

So that's not great.

A better idea is to use a distributed hash table. The BitTorrent Mainline DHT allows users to
lookup a document signed by an ed25519 key pair, by specifying the ed25519 public key as well as a
short string. The DHT then assigns 20 computers to store and serve such a document, based on some
algorithm which isn't important right now. So the nature of the data: the key itself and the short
string (which we can define), determine which servers store that data. This is a natural fit.

The DHT only accepts such documents if they are signed by the ed25519 key pair that is specified in
the document's address. So nobody can squat on somebody else's space, clobber their record and deny
service. And the DHT prevents self-clobbering by versioning changes to that document, unlike
nostr's following lists which famously get clobbered by buggy clients.

On the security front, the BitTorrent Mainline DHT is the most secure DHT in the world. It is so
large now that it is virtually impossible to take down. It is more resistant to a Sybil attack than
any other DHT. Standing up a new DHT will never be anywhere near as secure.

OK. So what I just described is what Mosaic does right now. Except it actually does two steps. The
first document lists the keys of the servers that the user users, those keys representing those
servers, and then those keys have to be looked up in the DHT themselves to find the endpoints
where those servers are currently listening. Because remember, servers can now listen on multiple
endpoints.

By the way, Mainline DHT is also what pubky uses, via pkarr, except that pkarr uses the DNS protocol
on top of the DHT in order to cache and to provide service to browsers.

So those are the two major upsides of switching to ed25519, which essentially requires starting
over.

You might think that there is some tricky way to get around this and use secp256k1 key pairs with
the Mainline BitTorrent DHT and with TLS. But as far as I can tell, and I've thought about this and
run experiments, there isn't.

As for TLS, it might be possible to get TLS working with some kind of ugly hack but that would be
deep within TLS code and hard to make portable.

As for the DHT it is simply not possible.

For example: you could create a document that is indexed and signed by an ed25519 key that
includes your secp256k1 key and signatures proving a both-way binding between the keys. But then
you can't look this thing up starting from the secp256k1 key.

Or for example, you might think of using the same bits of your secp256k1 key but just interpreted
as an ed25519 key. But then you wouldn't have the secret half to sign with.

OK, the last thing I want to talk about within this topic is, if we have to start over with a new
identity cryptosystem, in what ways can we remain compatible? How big of a fork does this have to
be?

Mosaic is starting with support for device keys right from the start. The Master key has to be
ed25519 to work with the DHT. And the device keys for servers have to be ed25519 to work with TLS.
But the user's device keys for signing and encryption could use either cryptosystem.

Secp256k1 keys and signatures are the same length as ed25519 keys and signatures. So all we need is
a bit flag that indicates which cryptosystem is in use for nostr keys to be used in Mosaic.

That at least preserves identity mapping... which is big. This means it may be possible in the
future to find and follow the people we have already found and followed on nostr. I say in the
future because the Mosaic spec hasn't gotten that far yet. There would need to be a way to go from
a device key and determine which master key it is under, and Mosaic only specifies DHT entries for
the master keys, not the device keys. The right solution hasn't been thought out yet.

As for sharing existing or future events between Mosaic and nostr, this is much harder. Nostr
events can not be converted into Mosaic events without the assistance of the original author and
their private key. So I expect clients that wanted to interact with nostr would need to be
dual-stack at the record layer and the protocol layer, making Mosaic still a fairly significant
fork.

Of course there could also be a bridge, but bridges defeat sovereign identity. They are fine for
bridging between two protocols where one doesn't have sovereign identity, but seem deeply
insufficient for bridging between two protocols both of which support sovereign identity. We should
be able to do strictly better.

Any ideas for enhancing compatibility are greatly appreciated.

OK, that's all for today.