Nostr offers absolutely nothing more. Not without Pkarr. In fact Bluesky offers more because they have relays for reach just like nostr, but behind that there are datastores that are still useful on their own just like web servers, in applications that don't need a timeline or search.
This is a bad argument.
Maybe, but maybe not. You could argue that DDoS by definition means an attacker already has orders of magnitudes more computing power than the average user.
If you are running a Nostr's relay that doesn't delete users events, how do you fight spam without KYC? Demanding payment is very effective but limits how many people are willing to go through onboarding, what is the alternative? PoW?
In a system using Pkarr to point to a service provider, you get the best of both worlds, you get the ease of nsecbunker, and sovereignty of a (almost) cold wallet.
What part of the internet infrastructure enables routing so you can find people's server? And can we make that more sovereign and easier to provision?
Entire debate about whether or not Nostr is decentralized, when it is entirely a red herring metric, the only thing that matters is censorship resistance.
And Nostr can't achieve that properly without using Pkarr, sorry I don't make the rules.
nostr:npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz Do you have a technical opinion on the current EU Digital Identity Architecture and Reference Framework, EUDI ARF, on Github?
https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework
No, but sounds like a nightmare just having EU Iin the name
Also re. decentralized search: Negatives are hard to prove so I'd be careful with "it's not possible". This here looks promising:
https://www.cs.cornell.edu/~bwong/Cubit/
nostr:note154eyvuyvkrhf203ptx8dsnc63dexag2dwkpuhmet5kxaxkwlznasas8a6d
Sigh... anyone can make up this stuff, it is impossible, and I will bet money on that.
I didn't call it fake, I may have called it stupid,and it is, this conversation is too late though as Protocol Labs is imploding as they should have years ago, and Mainline will still be here decades from now.
Your "anti war" candidate is garbage.
I am a couple of months away from a working mvp of hosted ordered key value stores that don't lock you in.
What are the least amount of data you expect a backup should contain? Display names? Profile pictures? Nothing but the secret key? Would it be acceptable if you restore an app offline and you see no names or pictures?
Amethyst is much better now and definitely better than Plebstr, the latter was putting me off of using Nostr as its search was useless!
Hi all! I have just pushed a major update to the negentropy project. It implements protocol version 1 (previous was version 0).
The protocol has been simplified: ID size is no longer configurable, there are no more continuation ranges, and the output can be constructed in the same input-scan pass.
There is a new fingerprint function, based on an incremental hash. This allows fingerprints to be pre-computed and stored in a tree structure. The C++ implementation includes a B+Tree implementation that allows fingerprints to be computed without collecting IDs from the entire DB.
I have written a comprehensive article that goes over the theory of RBSR and the negentropy implementation:
https://logperiodic.com/rbsr.html
Comments are appreciated!
Finally, I have integrated the new version of negentropy and the B+Tree with strfry. It's in a development branch and not quite ready for production, but my testing indicates this will be a massive improvement for full-DB syncs, especially on relays with very large DBs. In-sync or nearly in-sync relays should sync almost instantly with negligible resource usage. Relays will also use the B+Tree for filters that contain only until and/or since, meaning that date-range full-DB syncs are also efficient. Syncing arbitrary filters works as before (but I have begun work to make these more efficient as well).
Unfortunately, this is a breaking change for the negentropy protocol (this really should be the last one!) and will also require a new DB version.
I'm going to take this opportunity to make a few more breaking DB changes, and plan to release strfry 1.0 after a beta testing period.
Beautiful, more efficient sync.
I am personally invested in competing with all of this stack from first principles, but I love to see this.
That is the reason why Farcaster is good as well, the global feed (at least early on) is front and center of the protocol, they went to extreme length trying to make downloading everything ever posted, as efficient as possible, and thus they got very good global view and search on such view.
nostr:note1ejy0tqrjzzc9d9esa2ugngrkskhjqkgsc06q5lp9cslejvq0k7nqp7ztcg
Bluesky already won the search, not in the official app, but in 3rd party apps thanks to their access to the firehose, granted, that is easy when you have a single data store, so we will see as federation is introduced, but regardless, search can't be decentralized, it is always a function of crawling and aggregation, and that itself is very expensive. It can be competitive, but it will always be as centralized as Web Search.
If you have been watching Pkarr, it is time to revisit it:
- Implemented Mainline DHT in Rust
- Adding Mainline to Pkarr Rust implementation.
- There is a did:dht method built on top it now, If that means anything to you!
- The Rust implementation is 2x faster and just as reliable.
This is how sovereign identity and TLDs will be implemented in serious projects that need them.
Minimal p2p, just enough to make everything downstream credibly exitable!
Pkarr now is being used in at least two projects, one for p2p Holepunching, and a DID.
Nothing of what I usually talk about, just a whole pleasently surprising surreal day.