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.
Interesting. Maybe the big idea is not the relay but the ‘atomic event’ (signed event). It either exists or doesn’t exist.
Both in unison. They solve for different problems.
I've been thinking about this too. The events can exist without the relays, technically, but the relays create the landscape. If the relays disappear, we're back to centralized servers, and there's no incentive for event interoperability.
Yes, relays multiple the events and spread them across many different, connected machines.
We spend a lot of time on data visualization. Maybe we should also visualize the relay system, nostr:nprofile1qqsdcnxssmxheed3sv4d7n7azggj3xyq6tr799dukrngfsq6emnhcpspz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9nhwden5te0dp5hxapwdehhxarj9ekxzmny9u78m52f , and calculate if the event storage and transmission is getting more or less centralized.
"Landscape" immediately sounds like something worth mapping and navigating by.
Perhaps we could cluster events by relay, or assign each relay a color, or give each event a number indicating how many relays hold a copy.
Even more far-out, a visualization could use relays as a third axis. A 2D plane shows the events and how they relate to each other on one relay. Look at it from the side in 3D, and there are many planes stacked atop one another, each one representing a relay.
It would be interesting to verify this. Nostr likely does have a power law distribution of users to relays. Preferential attatchment describes that when new users join a network they will join in a biased way, connecting to their friends and those that already have an established presence. Considering that Outbox isn't widely used, that many of the onboarding clients use their own relays, and that general users would be less likely to change their relay settings unless told to do so, I'd expect that we're still very centralized. Key factor - microblogging incentivizes following users, not content.
Maybe they just need new marketing. Although, "relay" does roll off the tongue better than "redundanator". 😜
Decentralization will always have slightly-worse UX than centralized systems because it can pre-scan and pre-chew and pre-fetch everything.
I think Nostr has a good balance, and outbox would improve it, but I underestimated the power of UX. Perhaps, because I'm used to working on terminals.
I think I also overestimated how much some people care about personal autonomy. A lot of people don't really care. Sort of the way everyone is for the free market and against central planning, but not really.
Bleeding edge tech frequently has "slightly worse" UX, but that changes over time. Some email clients and web browsers have great UX.
I think people care about autonomy, but only if the process is understandable, and easy. Convenience (unfortunately) is the path of least resistance for the masses.
This is why I cringed while reading the Nostr Telegram group when I joined Nostr almost two years ago. Back then, there was a lot of, "I can't wait until normies start groking relays and wanting their own." kind of discussions.
People would rather drive circles in a parking lot, versus parking in a space that's more than seven spaces from the front door. Normies don't want to deal with "under the hood" type stuff to perform basic (to them) operations.
If the concepts can be distilled down, and made for Idiocracy, then the masses will engage (for better, or for worse).
Yes, it's the question if they can burn the Nostr brand before the distillation is complete.
Jury is still out. I haven't given up.
This is the part nobody gets.
Nostr clients are defined as software interfaces that sign notes and read/write to relays. That's why my CLI is a client, even though it resides on the same Linux laptop as my relay, and can only be used over the terminal. Where clients reside or run (phone, remote server, local browser, cloud, desktop, refrigerator, etc.) isn't what decides that they are clients.
Nostr is, fundamentally, a client-server architecture, with the relay functioning as server (event store) and the client simply displaying what the relay sends it, according to the user's settings.
Placing an _additional_ server _between_ the client and the relay, is a fundamental change to the architecture. You can do that, perhaps because you want to curate or park the data, but as we can now see in real-time, many of their users didn't know they were doing that. It isn't immediately obvious.
Why is this significant?
The current setup means nobody can stop you from reading or writing whatever you want, and sharing it with a targeted or general group of others. The more relays get pushed back, the less this will apply.
I think Nostr apps need to come with client/relay pairs, but not so that users only have to write to one relay.
Publishing a relay with every app increases the number of relays. It also increases the proportion of relays that are tailored to a specific set of event kinds, as different apps will need relays focused on specific types of events. This will diversify the relay landscape, which contributes to the health of the Nostr network.
I like this, but I prefer having this custom relay in a setting or config file, so that someone doesn't have to change the code, to dislodge that relay.
I agree, it should be configurable. The default relay an app ships with should be a starting point, but the app should preserve the user's freedom to read from any relay he or she wishes.
Having a default relay intended to handle the types of events the app is built for gives a better user experience at the outset, as users don't need to manually configure a relay set to start seeing things on the app.
Notes and Other Stuff Transmitted over Whatever
Sure: run your own.
I believe in what you are saying.
Any educational resources which can help me get off of amethyst and run my own. So that I may be able to fully comprehend Nostr inside and out to have total control over my destiny.
Is very much appreciated. Right now I am in the educational phase of my adventure.
Amethyst is just the client that reads from the relays. nostr:nprofile1qqs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crspz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hszrnhwden5te0dehhxtnvdakz75w59d4 and nostr:nprofile1qqsw9n8heusyq0el9f99tveg7r0rhcu9tznatuekxt764m78ymqu36cpz4mhxue69uhkvun9deejuat50phjummwv5hsz8rhwden5te0wfjkccte9e3xjarrda5kuurpwf4jucm0d5hsz9thwden5te0wfjkccte9e6hg7r09ehkuef0avzrjf are some relay devs.
Strfry is the go to relay tech, it's one click deploy on stsrt9
relays have not been forgotten 😎😁🦕🦖
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.
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.
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.)
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.
I think it's hard for people to envision something truly relay-centric, rather than follow-centric. The closest we get, so far, is community clients limited to one particular relay.
We're sort of trapped in a social media cage.
Can you explain what you mean by the end of relays? How can nostr even exist without them?
