I don’t quite agree with some of the rationale

1. I do think users have benefited from Open Source, but I also think that there has been an a decline in Open Source software in general
2. I don’t think contracts are a good analogy here (in the sense that every corporate consumer of the software would have to sign one)

Having said this I do understand where he is coming from. And I agree that:

1. a lot of big companies consume this software and don’t give back
2. corporate interests are well entrenched in some Open Source projects, and some bad decisions have been made
3. he does raise an interesting point about the commons clause (but them I’m no laywer)

I would like to remind everyone that the GPL pretty much exists because of (1.). If anything we should have more GPL code. In that regard I don’t think it failed us. But we rarely see enforced (in court). Frankly most of our code is not that special so please GPL it.

Finally I think users do know about Open Source software indirectly. In the same way they find out their “public” infrastructure has been running without permit or inspection the day things start breaking and the original builder/supplier is long gone and left no trace of how it works.

Since these days everything is software (or black box hardware with firmware) this is increasingly important in public policy. And I do wish we would see public contracts asking for hardware/firmware what some already for software.

I wont get into the Redhat/IBM+CentOS/Fedora or AI points because there is a lot more going on there. Not that he is not right. But I’m kind of fed up with it :D

Ultimately you are trusting the relay server to hold your messages If the relay is not trustworthy, it could reveal those messages.

The only exception I know of are encrypted direct messages which are still held by the relay but are encrypted with the recipient’s key. These messages still have a cleartext recipient id (so the server can deliver them).

So, if the relay is well behaved

• messages are confidential between you and the relay
• direct messages are only delivered to the recipient and are encrypted
• most other messages are visible by anyone that can connect to the same relay
• btw the relay can enforce a list of people that can connect (i.e. a private server) or just make it harder via proof of work (to discourage bots)

If the relay server is operated by the forces of evil, then the only thing you can assume is that direct message content is not visible, but they can see the message src/destination/timestamp.

I think the main motivation for nostr is censorship resistence - so if you are being blocked in one relay, you move to another - in terms of privacy/security it does not seem weaker than most other public message forums.

They could serve similar purposes. In terms of maturity nostr is younger. Here are the main differences from the point of view of nostr:

• In nostr there is no registration, your identity is your public key that you generate by yourself (lose that and you cannot recover it). You can connect to a bunch of different nostr relays with the same key, or use different ones.
• AFAIK nostr does NOT do end to end encrypted for group chat. But it does support end to end encryption for direct messages
• nostr does not do video/audio calls
• nostr does not host your images/files, you just put some URL in your messages

At its core nostr is a basic protocol where you send messages to a relay server and the relay passes them along to other people when they request them. And on top of those messages people implement extensions for features, full length posts, payments, etc. The are notions of followers and subscriptions (like twitter) but those are just tiny messages where you ask the relay for messages from person A or B. The list of specifications is here https://github.com/nostr-protocol/nips

Finally there are a few different nostr implementations for relays, clients and web interfaces. Some of them do not implement all the features, so you may need to shop around a bit if your are looking for some fancy features (check https://github.com/vishalxl/Nostr-Clients-Features-List).

Also some nostr highlights which I think don’t have equivalent in matrix (but deserve nerd points)

• message expiration dates - the relay removes them after the deadline
• nostr has builtin proof of work to dissuade spam by forcing the client to do some computation before posting
• you can do reposts across relays or share relay addresses to people in another relay

As any engineer who does ops can tell you - you did the right thing - the solution is always to roll back, never force a roll forward, ever.

We should totally do pre and post update parties though. Even if the update fails we can have an excuse for drinks and a fun thread.

Very timely article and a good reminder for us to 1) release our software under strong copyleft licenses and 2) do not invest our time in software that does not do .1