Replying to Avatar Silberengel

I think we're slowly approaching the end of relays. Nobody seems to remember why we thought they were a good idea, but they're pretty sure that we don't really need them and the principle of the architecture is being whittled away at.

It's possible that relays are just considered too dangerous, subversive and uncensorable to be allowed to flourish, unchecked. Sort of like self-custodying your Bitcoin.

I remain a #RelayMaximalist in the #RelayUnderground.
Avatar
MichaelJ 1y ago

I'm not sure our developers are treating relays as first-class entities.

Earlier today, as I was Jira mapping our Aedile dev kit project, I was thinking about how to structure the code. What are the first-class entities, and how should they be represented by the class structure?

I've come up with four first-class entities on Nostr, from the client's perspective:

1. Events

2. Relays

3. Users (npubs)

4. Subscriptions (event filters)

A well-designed client library should give all of these equal importance.

What does this mean?

Well, for example, I should be able do both event.send(myRelays) and relay.send(myEvent). It's up to me as the client developer to figure out which method best supports the kind of user experience I'm trying to create.

A social client might use the first method; the important thing is to create events and push them out over the network. What relays the events live on is less important than being able to chat with other npubs.

A relay-centric client, on the other hand, would use the second method. The priority here is to be able to view and interact with only the relays the user chooses, perhaps because each relay is a community, or different relays specialize in different event kinds.

Clients seem to focus on events, first; I have yet to see much development work on relay-centric UX. While this state of affairs persists, relays will remain underappreciated.

Reply to this note

Please Login to reply.

Discussion

Avatar
MichaelJ 1y ago

For the record, I believe #Alexandria is well-suited to shake up this paradigm and create a relay-centric user experience, because that's what makes the most sense for the project.

Avatar
Silberengel 1y ago

Yes, because our mission says that we want to:

"Allow everyone to obtain and disseminate knowledge, without fear of censorship."

Which is an essentially different mission than a kind 01 client has. Kind 01 is mostly just social chatter and polemic, like on Twitter or Tik-Tok.

Making the heroic effort to create an uncensorable architecture and then using it to post food pics, AI artwork, Bitcoin price predictions, porn, and admonitions to "stack sats and reject seed oils" will inevitably lead to everyone wondering why you bother with all of that uncensorability. Why the additional effort, to protect things nobody earnestly wants to censor?

(That censorable things are also centralized, and that centralized storage is expensive, will be something people only realize later, to much chagrin.)

Avatar
MichaelJ 1y ago

The fact that large, centralized storage becomes expensive quickly will, I think, be a limiting factor in the growth of the relay network. An obvious solution is for relays to shed events based on some heuristic to prevent storage from growing out of control. This keeps relays affordable, but makes user data ephemeral.

To store events long-term, the user has to either ensure they are distributed across many relays so they are always out there somewhere, or pay for the storage space themselves.

I think paid storage is more likely. Some relays already do that; Wine is an example.

Another solution would be tiered storage. Perhaps some solutions will implement user-controlled cloud storage as a second tier. The user can designate outbox relays and event kinds to be stored long-term, and the second-tier permanent storage vacuums up the user's events from their outbox relays and stashes them. That storage solution can provide a DVM that re-introduces events to the relay network if they have been deleted.