-
@ 3bf0c63f:aefa459d
2024-09-06 12:49:46
# Nostr: a quick introduction, attempt #2
Nostr doesn't subscribe to any ideals of "free speech" as these belong to the realm of politics and assume a big powerful government that enforces a common ruleupon everybody else.
Nostr instead is much simpler, it simply says that servers are private property and establishes a generalized framework for people to connect to all these servers, creating a true free market in the process. In other words, Nostr is the public road that each market participant can use to build their own store or visit others and use their services.
(Of course a road is never truly public, in normal cases it's ran by the government, in this case it relies upon the previous existence of the internet with all its quirks and chaos plus a hand of government control, but none of that matters for this explanation).
More concretely speaking, Nostr is just a set of definitions of the formats of the data that can be passed between participants and their expected order, i.e. messages between _clients_ (i.e. the program that runs on a user computer) and _relays_ (i.e. the program that runs on a publicly accessible computer, a "server", generally with a domain-name associated) over a type of TCP connection (WebSocket) with cryptographic signatures. This is what is called a "protocol" in this context, and upon that simple base multiple kinds of sub-protocols can be added, like a protocol for "public-square style microblogging", "semi-closed group chat" or, I don't know, "recipe sharing and feedback".
-
@ 3bf0c63f:aefa459d
2024-06-13 15:40:18
# Why relay hints are important
Recently [Coracle has removed support](nostr:nevent1qqsfmgthccjuz7quucel20wjanh80sp8nxf5ujgpj5hwdzk8japavzgpzemhxue69uhky6t5vdhkjmn9wgh8xmmrd9skcq3qjlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qca68ht) for following relay hints in Nostr event references.
Supposedly Coracle is now relying only on public key hints and `kind:10002` events to determine where to fetch events from a user. That is a catastrophic idea that destroys much of Nostr's flexibility for no gain at all.
* Someone makes a post inside a community (either a NIP-29 community or a NIP-87 community) and others want to refer to that post in discussions in the external Nostr world of `kind:1`s -- now that cannot work because the person who created the post doesn't have the relays specific to those communities in their outbox list;
* There is a discussion happening in a niche relay, for example, a relay that can only be accessed by the participants of a conference for the duration of that conference -- since that relay is not in anyone's public outbox list, it's impossible for anyone outside of the conference to ever refer to these events;
* Some big public relays, say, _relay.damus.io_, decide to nuke their databases or periodically delete old events, a user keeps using that big relay as their outbox because it is fast and reliable, but chooses to archive their old events in a dedicated archival relay, say, _cellar.nostr.wine_, while prudently not including that in their outbox list because that would make no sense -- now it is impossible for anyone to refer to old notes from this user even though they are publicly accessible in _cellar.nostr.wine_;
* There are [topical relays](nostr:naddr1qqyrze35vscrzvfcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0z85e2) that curate content relating to niche (non-microblogging) topics, say, cooking recipes, and users choose to publish their recipes to these relays only -- but now they can't refer to these relays in the external Nostr world of `kind:1`s because these topical relays are not in their outbox lists.
* Suppose a user wants to maintain two different identities under the same keypair, say, one identity only talks about soccer in English, while the other only talks about art history in French, and the user very prudently keeps two different `kind:10002` events in two different sets of "indexer" relays (or does it in some better way of announcing different relay sets) -- now one of this user's audiences cannot ever see notes created by him with their other persona, one half of the content of this user will be inacessible to the other half and vice-versa.
* If for any reason a relay does not want to accept events of a certain kind a user may publish to other relays, and it would all work fine if the user referenced that externally-published event from a normal event, but now that externally-published event is not reachable because the external relay is not in the user's outbox list.
* If someone, say, Alex Jones, is hard-banned everywhere and cannot event broadcast `kind:10002` events to any of the commonly used index relays, that person will now appear as banned in most clients: in an ideal world in which clients followed `nprofile` and other relay hints Alex Jones could still live a normal Nostr life: he would print business cards with his `nprofile` instead of an `npub` and clients would immediately know from what relay to fetch his posts. When other users shared his posts or replied to it, they would include a relay hint to his personal relay and others would be able to see and then start following him on that relay directly -- now Alex Jones's events cannot be read by anyone that doesn't already know his relay.
-
@ 3bf0c63f:aefa459d
2024-06-12 15:26:56
# How to do curation and businesses on Nostr
Suppose you want to start a Nostr business.
You might be tempted to make a closed platform that reuses Nostr identities and grabs (some) content from the external Nostr network, only to imprison it inside your thing -- and then you're going to run an amazing AI-powered algorithm on that content and "surface" only the best stuff and people will flock to your app.
This will be specially good if you're going after one of the many unexplored niches of Nostr in which reading immediately from people you know doesn't work as you generally want to discover new things from the outer world, such as:
- food recipe sharing;
- sharing of long articles about varying topics;
- markets for used goods;
- freelancer work and job offers;
- specific in-game lobbies and matchmaking;
- directories of accredited professionals;
- sharing of original music, drawings and other artistic creations;
- restaurant recommendations
- and so on.
But that is not the correct approach and damages the freedom and interoperability of Nostr, posing a centralization threat to the protocol. Even if it "works" and your business is incredibly successful it will just enshrine you as the head of a _platform_ that controls users and thus is prone to all the bad things that happen to all these platforms. Your company will start to display ads and shape the public discourse, you'll need a big legal team, the FBI will talk to you, advertisers will play a big role and so on.
If you are interested in Nostr today that must be because you appreciate the fact that it is not owned by any companies, so it's safe to assume you don't want to be that company that owns it. **So what should you do instead?** Here's an idea in two steps:
1. **Write a Nostr client tailored to the niche you want to cover**
If it's a music sharing thing, then the client will have a way to play the audio and so on; if it's a restaurant sharing it will have maps with the locations of the restaurants or whatever, you get the idea. Hopefully there will be a NIP or a NUD specifying how to create and interact with events relating to this niche, or you will write or contribute with the creation of one, because without interoperability none of this matters much.
The client should work independently of any special backend requirements and ideally be open-source. It should have a way for users to configure to which relays they want to connect to see "global" content -- i.e., they might want to connect to `wss://nostr.chrysalisrecords.com/` to see only the latest music releases accredited by that label or to `wss://nostr.indiemusic.com/` to get music from independent producers from that community.
2. **Run a relay that does all the magic**
This is where your value-adding capabilities come into play: if you have that magic sauce you should be able to apply it here. Your service, let's call it `wss://magicsaucemusic.com/`, will charge people or do some KYM (know your music) validation or use some very advanced AI sorcery to filter out the spam and the garbage and display the best content to your users who will request the global feed from it (`["REQ", "_", {}]`), and this will cause people to want to publish to your relay while others will want to read from it.
You set your relay as the default option in the client and let things happen. Your relay is like your "website" and people are free to connect to it or not. You don't own the network, you're just competing against other websites on a leveled playing field, so you're not responsible for it. Users get seamless browsing across multiple websites, unified identities, a unified interface (that could be different in a different client) and social interaction capabilities that work in the same way for all, and **they do not depend on you, therefore they're more likely to trust you**.
---
Does this centralize the network still? But this a simple and easy way to go about the matter and scales well in all aspects.
Besides allowing users to connect to specific relays for getting a feed of curated content, such clients should also do all kinds of "social" (i.e. following, commenting etc) activities (if they choose to do that) using the outbox model -- i.e. if I find a musician I like under `wss://magicsaucemusic.com` and I decide to follow them I should keep getting updates from them even if they get banned from that relay and start publishing on `wss://nos.lol` or `wss://relay.damus.io` or whatever relay that doesn't even know what music is.
The hardcoded defaults and manual typing of relay URLs can be annoying. But I think it works well at the current stage of Nostr development. Soon, though, we can create events that recommend other relays or share relay lists specific to each kind of activity so users can get in-app suggestions of relays their friends are using to get their music from and so on. That kind of stuff can go a long way.