#asknostr
test1's avatar test1
Yeah, it was a failure from the so-called social Nostr influencers... Nostr is great for infrastructure, but for social media it's only useful if you have something relevant to say that needs censorship resistance. Otherwise, users who don't have much to contribute are useless, and they would be better off staying on a traditional social platform unless they need uncensored media and free speech.
View quoted note →

Replies (20)

Meh. IMHO we mainly just need to “fix identities”. Bitcoin stored in a wallet is a fungible asset that can be replaced if lost, your nsec is unique… and not quantum resistant, so the longer we postpone adopting proper PKI, the worse it will be.
Well, you know how much demand there is for solutions like Inkan. There is a better solution right now for posting to the Nostr protocol, and adoption is really minimal, even when the client is cheap or free (including time and cognitive costs, of course). Initially, demand for BTC was for more transactions without intermediaries, but it quickly changed to a speculative investment for the majority, so demand for the emergent behaviour is greater than its original proposal... I think BTC was truly the focal point for a solution that was good enough compared to its predecessors.
The demand is here. nevent1qvzqqqqqqypzq5xeflpdskqvdq4swxj59793uvdzqzc9pzatjk3nhmcg2h0js8trqyg8wumn8ghj7mn0wd68ytnddakj7qpqpw6d4ug8cyy5zrv959ferh2fv8j8l2tul37nt7purgwlpw6y65cswydjsx But I am starting to wonder if the perceived apathy is a sign of good old skill issue. Consider this proposed workaround for the repeating pattern of follow lists being nuked: nevent1qvzqqqqqqypzq5xeflpdskqvdq4swxj59793uvdzqzc9pzatjk3nhmcg2h0js8trqy88wumn8ghj77tpvf6jumt99uqzpz24fw6fm220dnzlmlacm8ln6ypexcqfajy5vtnkqgfpdfpre5aq8u7ft3 Someone came up with an implementation of that idea a few hours later: From my perspective CRDTs (or something similar) are the obvious solution for this kind of problem (it could also help with the long standing problem of follower count), but that sounds complex and complex is scary. Somehow, a half-baked mitigation at the relay level is perceived as a good solution because it can be hacked into existing infrastructure without much changes, which in turn actually increases the complexity without giving a proper return. Nostr “simplicity” is deceiving. It can only afford to stay simple so long as it does not work. Distributed systems are hard, but now you sold a hard system for people who want to brute force their way out of problems with “simple” solutions that only make the system more brittle and unreliable.
PABLOF7z's avatar PABLOF7z
Serial killer relay A Nostr relay implementing NIP-EC — relay-enforced linear event chains. (Aka a way to make it impossible to accidentally wipe a follow list or break state accidentally) https://github.com/pablof7z/serial-killer Cc @calle
View quoted note →
Sorry, but what are 'CRDTs'? I'm just a power user with auth interest in the development of public key protocol schemes. I'm not a developer, but I'm certainly not a casual user. thanks for your time, we need more people like you.
The fact that very few developers, PGP users or niche Bitcoin users are interested demonstrates that there is little demand. While it is currently non-existent, a good enough key rotation system could certainly meet this very niche demand for business and other use cases. Implementing this could be mildly successful, as it is with BTC — reaching more or less 1–2% of the world's population. Totally agree with your analysis on the implementation of work around solutions, can it get it messy in a few years because bad architecture shit on meaningful and more clean upgrades... For example, it is difficult to achieve a high level of privacy with Bitcoin transactions because its architecture is simpler. Monero, on the other hand, has a more complex base architecture, but it has been implemented cleanly as an anonymous medium of exchange.
From > Conflict-free Replicated Data Types (CRDTs) are used in systems with optimistic replication, […] CRDTs ensure that, no matter what data modifications are made on different replicas, the data can always be merged into a consistent state. This merge is performed automatically by the CRDT, without requiring any special conflict resolution code or user intervention. > Moreover, an important characteristic of CRDTs is that they support decentralised operation: they do not assume the use of a single server, so they can be used in peer-to-peer networks and other decentralised settings. In this regard CRDTs differ from the algorithms used by Google Docs, Trello, and Figma, which require all communication between users to flow via a server. Practical example: instead of republishing a follow list every time I follow or unfollow someone, I make a follow event with the npub I am interested in following (or unfollowing). Then my client can compute the follow list locally, from the follow and unfollow events. Suppose that I follow someone from a desktop client but the event did not propagate to every relay I use and/or my phone has been disconnected from the internet for a long time and/or it can only connect to the other half of relays etc and I decided to follow someone, it is just an event. When connectivity normalizes or you sync your phone with your computer directly over bluetooth (amethyst) or FIPS (nostr vault), they will accept each other’s follow events and converge into the same computed follow list - all without special casing, conflict resolution code (like nostur has) and overall it has less complexity and more guarantees than the proposed “event chains”. I also suppose it would make calculating follow counts easier (rather than inspecting an unbound number of follow lists you could just request follow/unfollow events filtered by npub).
Or these people could simply be using something other than nostr, precisely because it does’t suit their needs. Remember when @Edward Snowden last posted anything here? Or that thread when someone pointed out every way in which nostr failed independent journalists reporting from shitholes? Sane key management is not a niche, it is a basic feature of every PKI. When you ask that a user pastes a secret that is supposed to be their personal identity into a vibe coded app and tell them “btw you can’t revoke, rotate or otherwise upgrade the security of this” (in other words, there is no “password reset”, no social recovery whatsoever) you are not being serious. And to be fair not even inkan fills all the checkboxes: implying that an airtight environment and full self custody addresses some of the problems, but not all of them. @npub1jvxv...7yqz also has designed an identity system, which seems to address the onboarding problem much more effectively, but I don’t know exactly how it works to make a fair comparison. Still, whenever you ask client developers about proper key management, some will answer that they “don’t care about their identity because they only use it for shitposting”, claiming that generating a new keypair is cheap etc. So there is demand and you even have some people willing to work into these kind of problem but you also have a huge inertia problem coming from widespread client implementations, which would much rather take the easy path of handing nsecs over to big tech. Maybe the nostr’s fate is to be a way to relay info between machines: FIPS discovery, ephemeral agent communication and “other stuff”. But when that happens, the stubborn fucks will claim that it is the people’s fault for being “too normie” and “not understanding nostr”.
I will post some data to back up my claims. I have over 50 UTXOs and the list on Inkan is really small. As far as I know, keyservers are stuck on numbers and not booming. I have an advanced BTC setup, and if we calculate that the average user has 10 UTXOs, there are around 16 million sovereign users in the world. The TX input data on the mempool is also really low. The demand for sovereign key management is low. In my opinion, Inkan would be better if it could be implemented on the BTC/Rootstock chain and its requirements were relaxed. In my opinion, an app like Amber on a used phone with delegation and key signing features similar to those of Cupcake (for CakeWallet-signed transactions) would be easier to set up than a modified Tails. Having a small user base for social features is fine. I don't see how the protocol would improve with a large influx of DiVine users on Nostr, except that they would get more privacy and freedom in exchange.
↑