https://github.com/nostr-protocol/nostr
Fun facts about Nostr:
* Nostr stands for "Notes and Other Stuff Transmitted by Relays". It is an odd acronym, but I like it.
* Nostr uses websockets and relays to build a really simple P2P network. We also steal a few ideas from bitcoin (ECDSA ids, schnorr-signed events).
* Relays are simply dumb data stores for events that clients publish and subscribe to.
* Clients don't trust relays to be honest, so all events are self-signed. Your pubkey is your userid.
* It is stupid simple to build a Nostr client. You can easily do it in less than 400 lines of JavaScript. And it runs in the browser.
(shameless self plug) https://github.com/cmdruid/nostr-emitter
* Nostr is powerful enough to host chat apps very easily. Here is a rip of Telegram, running on Nostr:
https://anigma.io
* There's a lot of fun things you can do with Nostr. Check out all these cool projects!
https://github.com/aljazceru/awesome-nostr
* We are constantly discussing how to improve the protocol. Come join the conversation here:
https://t.me/nostr_protocol https://anigma.io https://damus.io https://github.com/nostr-protocol/nips
Thank you for reading my nostr shill post. I did not create nostr, nor do I get any monies for promotion. I just think it's really cool and I have a lot of fun building stuff that punches though nats.
If you have any questions about nostr please feel free to ask.
Also, Happy Thanksgiving to everyone! I hope we're all feeling fat and sassy today. :-D
https://abovethelaw.com/2022/11/hey-elon-let-me-help-you-spe... is a pretty decent rundown of a mix of these things; it is specifically pointed at Elon Musk's decision to buy Twitter and make it a haven for "free speech" but it is a glimpse at what is in the future for anyone setting up a "free speech" platform.
My experience as someone who has been running a Mastodon server since 2017 is that while "we are all for FREE SPEECH, we only block what the government ABSOLUTELY requires us to block!" sounds noble, in practice nodes of the Fediverse that say this become havens for people who are only there to be assholes to other people, and any sane admin will sigh and block the whole server, because it's just going to be a continual source of rude nasty bullshit.
P2P services OTOH work on a decentralized and pull model. Users share and only subscribe to the content they're interested in. Censorship is distributed, and it's a problem for people who don't wish to see specific content. It's the way the internet works, and the existing approach of removing sensitive content applies to P2P services as well. Since there are no advertisers to appease, it's not an existential problem.
The question was, to wit, >How do you keep CP off it?
Your answer was: >I don't, just don't look at the CP.
The problem really in question here is:
You've just created a new distribution method for this type of thing and punted the consequences for someone else to deal with.
(Which is totally cool imo, but newsflash, expect to be the subject of a hit piece some time in the forseeable future. It shouldn't take long; either for actual criminals to set up on it, or for LE to do it to "snare unsophisticated actors").
Welcome to the Internet, where we can't have/make nice things anymore.
> I don't know, but I imagine it has to do with the fact that people making social networks are either companies wanting to make money or P2P activists who want to make a thing completely without servers.
Except it has been done. In fact, that’s literally what KaZaA was with its “superpeers”. And what they realized was that by making a semi-decentralized system, they just introduced the weaknesses of both systems (slow downloads via peer-latency and network limits + easy censorship by killing relays/nodes). In addition, this is exactly how IRC works, despite the fact that it’s mostly used with a few nodes these days.
I’m not against semi-decentralized systems. They’re great and help deal with some scalability problems; but they don’t solve for the number one issue most people moving to decentralized are seeking (anonymity, privacy and free speech), so it’s not fair to compare it to platforms/protocols that do offer those features.
I like that nostr abstracts this problem away from the relays. Relays only focus on storing data and handling subscriptions. They can choose to censor and/or curate content if need be, but it's not their concern.
It's up to the client to come up with a solution, and that client can be a platform or a protocol of its own.
edit it also feels really great to work on that problem from the application layer. I can come up with a solution that isn't confined to the parent protocol.
Commonly filtered things (account block lists, post flag lists, filter rules, etc.) could be shared via the same system — indeed there could even be competing versions and everyone could follow their preferred filter source.
Users would also likely run statistical and machine learning based spam and content filters locally (perhaps on a personal relay/server of some sort, or an account on a shared one) configured to their preferences.
I would expect the infrastructure running such a network to be in the same position as Signal, who do not know the content of messages and can't censor them, leaving individual clients to figure out blocking etc. (albeit the client side options as well as ways to share configurations etc. would need to be much more advanced for a social network or similar than for a messaing app).
There are solid laws protecting copyright everywhere yet it is stilm trivially easy to find copyrighted content available for free online. Laws dont mean anything unless they are or can be enforced.
I'm not piling on nostr here, that's an issue with ActivityPub as well as most decentralized platforms/protocols?
Of course this doesn't work for people wishing to remain anonymous.
I wrote a simple directory you can use to find users and channels here: https://nostr-fzf.netlify.app
Though at this point I probably wouldn't use that either.
But I wouldn't be surprised if he was discouraged from continuing this work because ultimately people like ActivityPub because server admins can be little dictators that censor and ban at will.
ActivityPub isnt the only distributed thingy to learn that lesson. There are a reason the various ultra-free-speech hosted on the dark web, things never take off.
Mastodon, Pleroma et al. are not really ActivityPub implementations. Each of the fediverse clients implement some random 10% of AP and just try to get compatible with each other using dirty hacks.
From the sounds of it, you have the protocol but not the policy. Which is by itself huge that they are separate, but now the clients (?) needs flexible policy, no? Otherwise its just going to turn into a billion people all talking in the same room, or your going to have a ton of tiny rooms with no activity. The discoverability of interesting rooms will be difficult. Its sorta the IRC problem in a nutshell (or discord/etc). Balancing the noise, vs the quiet is the difficult part (AFAIK).
There are a number of web servers that host content (either for free or for money) [called relays].
Clients download recent posts
Identity is based on public key, allowing users more control and the ability to easily change relays.
So is RSS + pubkey based identity the right way to think about this?
Initially restrained from posting it, since it's possibly rather grumpy, and the authors seem to have fun with the protocol, but here it is.
The protocol doesnt want users to run their own servers, but there also aren't really any incentives to run relays, so what happens when it gets big enough that running a relay is expensive or non-trivial? I feel like it would just fall back to users running their own servers like in mastadon.
Relays have to figure out how not to get smashed with too much data. I predict they will require an account/login at some point. But you can post to multiple relays and drop relays that don't serve you well at any time.
There are still features that many apps will need such as tying multiple devices to an identity, abuse prevention for relay operators, etc.
I agree, except for the bit about public keys as identities.
I think public key identities are a step in the right direction, but there’s still a gap between that and what the ultimate solution is going to wind up being.
We need to have some layer of indirection between user identities and public keys so that users can do things like rotate keys, have multiple keys, and recover their identities.
I don’t know what the right solution to that is; I think it’s an open problem and probably one of the most important ones to solve. Keybase probably came closest to a good solution, but it wasn’t decentralized.
Both seem to use a “signed rotation” approach. Algorand keeps your public key stable while adding metadata that your spend key has changed and links the two. Atproto similarly uses the recovery key to sign a rotation op which can regenerate your signing key, additionally readjusting the tree to preattack state (by setting prev of the rotation to the last precompromise state).
This seems like an improvement of some kind, but still leaves gaps for lost keys. Keybase style approach, or multisig social recovery may also help.
And even if you're ok with the master key, the only way to solve this without centralized providers is with blockchains. A blockchain for rotating keys doesn't make sense.
But I do want to know if you're ok with a master key and subkeys that can be rotated.
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...
Easy rotation and recovery of individual keys, but you do have to protect your master seed.
Nostr also supports user verification through DNS hostnames.
Multiple keys: nothing to change. Works like that now.
Recover your identity: Well, if you want a well-known identity use NIP-05/NIP-35 and just change your .well-known/nostr.json file to point to your new identity, the one that hasn't been stolen. Hopefully nostr clients of your followers will respect that (who knows what programmers actually will do).
I think these problems are easier than you think they are.
- Proof of work: computing some hash, which is not enough to be onerous but enough to reduce spam
- micropayment over Bitcoin lightning network
One of the neat things about nostr is that while it has already been used to build a decentralized Twitter like social network, the protocol could also be used to build encrypted P2P chat, traditional discussion forum, alerting/push style notifications, and numerous other applications.
A lot of p2p protocols cheat with relays, it is really hard to traverse nats otherwise.
Nostr can be used for peer discovery to bootstrap a direct p2p connection.
You could also use a client/relay hybrid application, similar to other p2p networks. That would be fun to build. :-)
Relays are important for two reasons: peer discovery and communicating when one of the parties is offline. Same as with other p2p networks.
Edit: i RTFA. Sounds like relays can be run by anyone. That sounds p2p enough to me.
You can request very broad subscriptions from relays! For example, here is a site that subscribes to everything, showing you a gods-eye view of events streaming into a relay:
Events have different "kinds", so you can filter this based on the type of traffic you are looking for (like public posts or user profiles).
Platforms like damus.io are more user-friendly, and offer better tools for discovering users and content.
You can subscribe to a user's feed via their pubkey, so discovery methods typically revolve around learning pub keys.
I doubt anyone has ever been successful into signing up on any social platform and just followed the big names that are suggested automatically at the beginning or based on some "key interests" you select.
But hey, if you want that, it's easy for a third-party website to grab a ton of public Nostr data and build custom recommendation lists and whatnot.
See FAQ, second question.
It feels nice when a protocol has its core devs on the same wavelength as application devs. That's the feeling I get with nostr.
It's not shilling. It's recommending. Shilling is a bad thing. It's a simple thing.
Can you elaborate on this point? It would seem that meshing relays would've facilitated the dispersal of updates.
Nothing in the protocol specifies relay-to-relay communication, but nothing stops them either.
There is tremendous value in a much simpler protocol, especially if it can deal with the identity migration issues that Mastodon has faced since day one.
From what I've read, it sounds like the interoperability issues come from not implementing AP the same way as Mastodon rather than anything specifically protocol-related. Hence, e.g., Pleroma going out of its way to be Mastodon compatible as a design goal and GoToSocial having lots of issues because it hasn't yet gone that route[1]
[1] e.g. they have an issue where some client apps don't work with GTS because GTS doesn't advertise a version number sufficiently high enough - because the apps are looking for "v > 2.10 because that's when Mastodon introduced feature Z".
OTOH websockets are hard outside the browser :(
