Some people think Nostr cannot work with things like a "universal consistent like count" and other basic social media malignant tumors.
Even if we ignore the bad psychological and societal effects of such practices and assume they are good, and even if we assume that Nostr is all running in a single server that has all the events (a Bluesky-like unavoidable requirement for such universal consistency) these people are still completely oblivious to the fact that anyone can create a bazillion keypairs and spam like counts.
So when they ask for a "universal consistent like count" what these people are really asking for is for a centralized KYC barrier at the doors of Nostr that ensures only a single keypair can be created by each human.
Pushed a new nos2x update, with marvelous changes:
NIP49 support
A button that sends you to the options page on first install so you can generate or setup your key
A link to nosta.me so you can set up your profile after setting up your key
Probably some bugs because I did that while half-asleep yesterday
These come from adaptations I did over the work of two brave contributors that dared to wait months before their PRs were first merged and subsequently heavily modified.
The main problem I have with blastr (@5be6446aa8a31c11b3b453bf8dafc9@mostr.pub) is that it works too well. So well that lots of nostr software is broken and the developers don't even know it is broken because blastr fixes it for them. It is like everybody is riding their bicycles with training wheels on, and we don't have a clear idea who what software would fall over if the training wheels came off.
If events were not being copied (at least for a while) then the community of devs could find and fix the insufficiencies. But is that a pipe dream?
Secondarily, I don't like the inefficiencies of copying events all over the place and I think that won't scale as nostr grows. But that is a self-correcting problem.
These models of following people have different properties. Compared to the outbox model, the inbox model has these properties:
The publisher improves their reach by pushing their events to many relays
It is easy to see and count who is following the publisher
The publisher can cut you off, and you cannot follow someone secretly under this model
Readers only have to read from their own approved relays, not random ones they might not trust. This might also be nice for power-limited phones.
Worse overhead because events are copied to all the recipient relays, which might be a lot of copies.
It is not clear where reactions and replies go, or if everybody participating in a converstaion sees the reactions/replies of everybody else participating
They must still have an outbox relay unless they really want to not get their message out in the world for all to see -- which is the default behavior for people who use Twitter and so on.
I didn't mean to downplay the challenges, and I don't even think outbox/gossip model is the only solution or the best (although I can't think of anything better at this point). All I did was to complain about the current state of things and wish they were better.
Nostr cannot compete against the big platforms on the same field. If you try to make Nostr apps exactly like Twitter they will just be an inferior copycat. Nostr's competitive advantage is the fact that it is an open protocol, trying to hide that from users is the asking for defeat.
Why can't Nostr polls be just like "like" reactions? You vote you vote, it's just an event. If it works for reactions it works for polls. Spam and sybil filtering must be made at the reader client or at the relay level, just like for reactions.
The fact that Primal has a public relay (with hopefully all the Primal data accessible) at wss://relay.primal.net/ is very good news, now Nostr is not going to have to become a bloated mess and adopt their internal API semantics as part of the protocol anymore just because people clients want to query their database from external clients.
You mean the Nostr protocol should support all the methods the Primal API supports? It only works in Primal because the client is trusting a single server to have all the data. For any other clients it makes no sense to trust any small or closed relay with aggregated queries like that, you'll just get bogus data.
Unless you're of the opinion that Nostr should just have a single server with all the data and all the clients will just connect to that, that's the Bluesky vision.
Idea: an extended query layer for Nostr, with more expressive queries than just filters and the ability to do things like aggregations and counting
Your app would generate queries like "how many distinct pubkeys have reactions that reference this note", instead of asking each relay for all reaction events that reference said note and aggregating it locally.
You could this plug this into anything: something like @32e1827635450ebb3c5a7d12c1f8e7@mostr.pub 's NostrDB, a service you host at home to reduce bandwidth usage on cellular or just something that translates it to queries sent directly to relays.
It would allow for stuff like low bandwidth Nostr clients while not sacrificing decentralization, and making dev work easier.
There is no Nostr source, each software is completely independent from the others. Nostr is just a loose set of idioms they use to talk to each other. The NIPs are just documentation on the specific idioms used that exist to allow new people to write new interoperable software.
But seriously, instead of follower counts an engagement metric calculated from the amount of replies and whatnot that your posts receive would probably be easier to do in Nostr and more valuable for end users.
