Eana on Nostr: Trying out nostr for the first hour, and here are some of the things I have in mind. ...
Trying out nostr for the first hour, and here are some of the things I have in mind.
Since the way it designed is based on a distributed network of relays just like torrent trackers, it would be important to maintaining a list of performant relay servers in order to have a smooth experience, and hope that notes of people you follow would also get relayed to you.
In addition, every client/tab you open would be a flood of websocket connection to all “preferred relay servers” you listed. Which could potentially impose pressure to the relay network.
NIP05 verifications tend to be useful if someone owns a domain or belongs to an org that owns one. Otherwise people might just flood into services that gives out these verifications for free. Returning a JSON based on URL isn’t any costly nowadays anyway.
Also, giving the nature of the service, media sharing would all rely on links. Rich formatting relies on the client support, and probably no support of language filtering, polling or other rich interaction stuff.
It is a good thing that the network does not rely on one centralized server, but relies on relay servers means there’s not even a single server that you could rely on for your data. I’m not really sure how data export would work in this case.
Discoverability of content might be even worse than ActivityPub Fediverse. ActivityPub is constructed on the basis that each piece of content having a public URL, which when set up properly, could be discoverable by search engines. While nostr notes are basically indexed by a random hex linked to a public key, and is needed to be queried from a relay server. If no relay server expose these contents dynamically, it would be practically impossible for search engines to crawl the contents.
Overall, it is an interesting concept to implement. It fixes some issues of traditional or federated social media platforms, but introduces some other issues that others didn’t have. Anyway, nothing is perfect, and nothing need to be.
Since the way it designed is based on a distributed network of relays just like torrent trackers, it would be important to maintaining a list of performant relay servers in order to have a smooth experience, and hope that notes of people you follow would also get relayed to you.
In addition, every client/tab you open would be a flood of websocket connection to all “preferred relay servers” you listed. Which could potentially impose pressure to the relay network.
NIP05 verifications tend to be useful if someone owns a domain or belongs to an org that owns one. Otherwise people might just flood into services that gives out these verifications for free. Returning a JSON based on URL isn’t any costly nowadays anyway.
Also, giving the nature of the service, media sharing would all rely on links. Rich formatting relies on the client support, and probably no support of language filtering, polling or other rich interaction stuff.
It is a good thing that the network does not rely on one centralized server, but relies on relay servers means there’s not even a single server that you could rely on for your data. I’m not really sure how data export would work in this case.
Discoverability of content might be even worse than ActivityPub Fediverse. ActivityPub is constructed on the basis that each piece of content having a public URL, which when set up properly, could be discoverable by search engines. While nostr notes are basically indexed by a random hex linked to a public key, and is needed to be queried from a relay server. If no relay server expose these contents dynamically, it would be practically impossible for search engines to crawl the contents.
Overall, it is an interesting concept to implement. It fixes some issues of traditional or federated social media platforms, but introduces some other issues that others didn’t have. Anyway, nothing is perfect, and nothing need to be.