What about with the federation stuff and alternative URLs? A relay could keep its canonical url, but still be available on alternate domains (or even transports). The relay could also advertise active replication of content with another, entirely separate relay.

Reply to this note

Please Login to reply.

Discussion

How do you access/manage all these alternative relays in the most straightforward manner?

👉 with a key pair

So you might as well have used that from the get go and avoid all the complexity.

With just relays:

- you move the problem to the relay

- are still very dependent on your relay service provider

- have worse (non-Nostr) identifiers

...

Keypairs do not already function like groups. Relays do, which unlocks progressive enhancement — one part of which is adding a keypair so it can publish notes on its own behalf.

Keys do not make good groups, believe me, I tried it: https://github.com/nostr-protocol/nips/pull/706

You can already fetch all kind 1s on a relay.

You can already fetch all kind 1s targeted at an npub (on their inbox relays).

Both can function like a community.

Both are currently not used like that.

Only the latter gives me what I need.

Until you want to enforce access control or moderation, then you're in rube goldberg land

For reliable access control and moderation, you need your own relay.

I love those incentives.

How do you manage that relay? 👉 With a key pair.

How do create multiple groups on that same relay, without having the NIP-29 mess? 👉 With key pairs.

How can you try out groups/communities without having to run a relay? 👉 With a key pair.

Or MLS, which granted is hard to implement, but fits this problem like a T

Yes, MLS may yet save us from this madness