Oddbean

I thought this too for a long time. But then I realized if i have exclusive content, and publish it to certain relays, but there are other relays I dont like, I'd be a bit annoyed if they take that content. There's gonna be a spectrum of opinions on this, I respect yours, but I have come to have a more complex view over time e.g. things like NIP-70 introduces nuances: https://github.com/nostr-protocol/nips/blob/master/70.md

The unwritten rules of respecting robots.txt and not scooping up everything have already crumpled due to AI scraping. https://www.businessinsider.com/meta-web-crawler-bots-robots-txt-ai-2024-8 Seems to be the trend that if you can access it it will be used. Encrypt and deny access might become the new reality, unfortunately.

I normally work on a different principle. So firstly I make things I want to use myself. And preferably that I can recommend to my friends. Many of whom are non techie. So, for example I can recommend bitcoin, because it's fair, innovative, and a level playing field, as far as possible, imho. Could I recommend a service where the norm is to take their (possibly exclusive) content and posts it elsewhere? No, that's not OK. Nostr was built as a small corner of the web that tried to aspire to be a bit better. So just because, say OpenAI are doing bad things (thanks for pointing it out, btw), doesnt mean it should translate to nostr. A reasonable user expectation would be they publish to the places they want, and if others republish that, they need consent, or user can be unhappy. Nostr itself says nothing about storage, replay attacks, or republishing, it just transmites, notes, and other stuff, from one user to another. Basic cypherpunk principle is not to harm the user, imho. Whether or not republishing does, is something that can be debated.

That was the way the Internet worked the first decades. Seldom it's worth the effort to try to chase after your rights if somebody misuses your copyright. This is the article I meant to share (and it's not just OpenAI): https://www.oreilly.com/radar/how-to-fix-ais-original-sin/

I think there is a conflation between enforcement ("How can I stop this") and ethics ("Should be we doing this"). You cant stop racism, but you can call it out. Definitely on nostr there are those that will want to post exclusive content on relays THEY choose. Perhaps a community relay, like a facebook group relay. I'm saying that data ownership should be respected, and people own their own data. You might not be able to stop it, but you can call it out. We have a web of reputation and trust already. Things like "antizaps" (negative zaps) are going to be quite important to call out bad actors.

Indeed. Robots.txt has worked for many years, and it was just a moral choice, not a technical barrier. Transparency is a good way to air out bad behaviour allowing others to see it and stop cooperating with a bad actor. There are ways to have strong “signals” and guardrails for the expected behaviour in the NIPs. Choice is a strong force. If you can choose the behaving relays, services etc. it goes a long way.

I think it's similar to publishing a Torrent. You publish it to the network, it does stay at a particular place. Mirroring is common and that's what will achieve decentralization of Nostr. At some point people will run their own relay and it will mirror notes they are interested in for easy access and archival. And maybe provide read access to others. I run my relay and mirror many things with a simple shell script from cron. The rule is - if a client can get it, so can a relay, which can act as a client. I own my data in a sense that I own my identity and that I have the archive of it that no one else can delete. But as Peter said, it's digital, can be copied and people have signed it with their keys. Internet does not forget.

Agree with most of this. However, torrents and social posts are not quite the same. Torrents are files that are designed to be shared. Posts could have some personal attachment. You could have a business nostr server. You could have a friends group. You could have special articles you want to share only in cretain places. You might share a party photo with some friends, that you regret. There is absolutely no default social contract in nostr other than you are using a websocket API over HTTP. If the system you use gets your consent, that's a different story. But if not, you can have the right to feel violated. Or not recommend nostr. The social contract is largely inherited from the status quo of users owning their own data, imho. Unless you agree to infinite sharing, which is also potenitally forever and undeletable.

I understood that the post button in most Nostr clients does post it to the network. There are no tools in Nostr to limit posting to some groups. You don't select where you post to in most clients, there are preferred relays, not ultimate relays, there are no per note relay sets anywhere in the user interface. It might be used like that in the future, when it's the responsibility of relay to limit writing and reading of notes to those that should be authorized. And that means not allowing connections from relays that could copy the notes. I see what you are saying as a potential problem in the future, but I think encrypted messengers are much better for sharing within a closed circle. Nostr is for public sharing, it's not encrypted, notes don't have any permissions attached to them except for the - tag, which is a self limitation like robots.txt. There's even a tool like http://nostrsync.live/ which will download all notes created by an npub from a list of a lot of relays and try to publish it everywhere. Note that authorization is not required, I can do it for your npub and the relays have no way of telling that you did not post that message to the relay, it's all valid signed notes.

Test CryptoClock 👍 before sending to #tbc2024 Customers. 🤔 #siamstr #nostr #bitcoin #cryptoclock https://nostrcheck.me/media/9553731295a77aa4213f5e11cfb6f05374f1a5fd37dd99c2989863497b44399a/a682c564a10a77a4a7133c0cebe6acf9e72259f1f69032b7ede078cf584eca5d.mp4