Collective thoughts on Nostr: There is a significant bug in Nostr that I refer to as "Leak Data." Initially, when ...
There is a significant bug in Nostr that I refer to as "Leak Data." Initially, when we created this protocol, our goal was to have complete control over our data. For instance, I have been trying to recover my Facebook account for 13 years; it neither allows recovery nor deletes my account, and my profile remains there without any direct means for me to pursue my rights. This means I have no control over that data.
Now that we have created a protocol called Nostr, why hasn't this goal been achieved? If I do not have control over my data, then I also lack freedom.
⦁ I have tested all the clients in this ecosystem, and they all have hidden connections behind the scenes. This means that besides Relay A, which I set up myself, there are other connections as well. This causes my data to be published on other relays, and I might not even be aware of it. If I decide to delete my account, how can I know if my data is also on Relay B so that I can delete it using NIP-09? For example, the Primal client connects to hidden relays even if you delete all its relays, meaning you effectively have no control over your data. If I want to retract something and delete that event, how can I succeed if that data has been broadcast from Relay A to Relay X and I'm unaware of Relay X's existence?
⦁ It is disastrous that some developers claim there is no need to encrypt media in direct messages. In fact, media in direct messages requires even more confidentiality than text does. For instance, the FreeFrom Official 𓅦 (nprofile…54nh) client uploads data to the server without any encryption.
⦁ The relay section in all clients is poorly designed; users do not understand the implementation mechanism well enough to know what role each relay plays. For example, the Amethyst client has designed this section more professionally by assigning specific sections to specific relays. However, in the final section where you set up a general relay, it causes changes in other areas like the outbox. Why was a general relay option designed that disrupts the outbox, inbox, direct messages, etc.? Or consider the Primal client, where the relays you configure are based on kind 10002 but realize that these settings have no effect; it still sends events to hidden relays from the user's perspective. Even in direct messages, instead of sending data only through the common relay between me and my contact, it sends data through dozens of relays.
In summary, I appreciate the idea behind the protocol and follow its development. However, this "Leak Data" bug that makes user connections opaque and prevents them from having control over their own data is very frustrating. Developers' mindset should prioritize privacy, security, and freedom; these should be their main focus rather than wasting time on trivial and useless matters.
Instead of working solo, why don't developers form teams where each one covers another's weaknesses and produces shared products? For instance:
@miljan userfriendly, @Vitor Pamplona focuses on performance. @Keychat emphasizes security
@hzrd149 supports various NIP
All of these products are filled with bugs and weaknesses; why doesn't one cover another's flaws? For example, the Primal client shows no concern for security; in fact, in its latest update, it removed the direct messaging icon from the main menu. Why doesn’t the KeyChat client address this weakness in Primal so that they can complement each other?
Now that we have created a protocol called Nostr, why hasn't this goal been achieved? If I do not have control over my data, then I also lack freedom.
⦁ I have tested all the clients in this ecosystem, and they all have hidden connections behind the scenes. This means that besides Relay A, which I set up myself, there are other connections as well. This causes my data to be published on other relays, and I might not even be aware of it. If I decide to delete my account, how can I know if my data is also on Relay B so that I can delete it using NIP-09? For example, the Primal client connects to hidden relays even if you delete all its relays, meaning you effectively have no control over your data. If I want to retract something and delete that event, how can I succeed if that data has been broadcast from Relay A to Relay X and I'm unaware of Relay X's existence?
⦁ It is disastrous that some developers claim there is no need to encrypt media in direct messages. In fact, media in direct messages requires even more confidentiality than text does. For instance, the FreeFrom Official 𓅦 (nprofile…54nh) client uploads data to the server without any encryption.
⦁ The relay section in all clients is poorly designed; users do not understand the implementation mechanism well enough to know what role each relay plays. For example, the Amethyst client has designed this section more professionally by assigning specific sections to specific relays. However, in the final section where you set up a general relay, it causes changes in other areas like the outbox. Why was a general relay option designed that disrupts the outbox, inbox, direct messages, etc.? Or consider the Primal client, where the relays you configure are based on kind 10002 but realize that these settings have no effect; it still sends events to hidden relays from the user's perspective. Even in direct messages, instead of sending data only through the common relay between me and my contact, it sends data through dozens of relays.
In summary, I appreciate the idea behind the protocol and follow its development. However, this "Leak Data" bug that makes user connections opaque and prevents them from having control over their own data is very frustrating. Developers' mindset should prioritize privacy, security, and freedom; these should be their main focus rather than wasting time on trivial and useless matters.
Instead of working solo, why don't developers form teams where each one covers another's weaknesses and produces shared products? For instance:
@miljan userfriendly, @Vitor Pamplona focuses on performance. @Keychat emphasizes security
@hzrd149 supports various NIP
All of these products are filled with bugs and weaknesses; why doesn't one cover another's flaws? For example, the Primal client shows no concern for security; in fact, in its latest update, it removed the direct messaging icon from the main menu. Why doesn’t the KeyChat client address this weakness in Primal so that they can complement each other?