https://theonion.com/sumerians-look-on-in-confusion-as-god-c...
- You don't need domain names for identity. Signatures are enough. An optional extension could contain emails and social handles in the payload if desired.
- You don't need terabytes of storage. All content can be ephemeral. Nodes can have different retention policies, and third party archival services and client-side behavior can provide durable storage, bookmarking/favoriting, etc.
- The protocols should be P2P-first rather than federated. This prevents centralization and rule by federated cabal. Users can choose their own filtering, clustering, and prioritization.
That's completely achievable in AP. Most current servers use reasonable retention, extended for boosted posts.
P.S. ActivityPub is a euphemism for Mastodon's protocol, which isn't just ActivityPub.
I feel like the "one feed" approach of most social platform is not here to benefit users but to encourage doom-scrolling with FOMO. It would be a lot harder for them to get so much of users' time and tolerance for ads if it were actually organized. But it seems to me that there might not be that much work needed to turn an RSS reader into a very productive social platform for sharing news and articles.
There is a major discovery problem and saying "out of scope" does not make it go away.
That said, the web has already developed a solution to this issue. It's basically just indexing. It's a very valuable technology, hence why Google got so much money from doing it.
You don't have to get all defensive about RSS, I think it's fantastic technology, but it is missing a few key components to be a replacement for social media in a meaningful sense. I know you know this, because you are here on a social media site right now instead of reading OP's feed. Whereas I don't want to ever leave my reader and instead consume news and recommendations and comments from my friends (of friends) right from there, instead of using gameable/botable centralized platforms with topics and moderators I don't control or trust.
My vision is not clear I know, I hope I can find time to prototype (or at least spec out) what I mean some time soon.
I wrote a specific XEP for the social part https://xmpp.org/extensions/xep-0472.html
And it's implemented in Movim https://movim.eu/
In other words what is missing is rules, regulations and incentives that are adapted to the way people use the digital domain and enforce the decentralized exchange of digital information to stay within a consensus "desired" envelope.
Providing capabilities in code and network design is ofcourse a great enabler, but drifting into technosolutionism of the bitcoin type is a dead end. Society is not a static user of technical protocols. If left without matching social protocols any technical protocol will be exploited and fail.
The example of abusive hyperscale social media should be a warning: they emerged as a behavior, they were not specified anywhere in the underlying web design. Facebook is just one website after all. Tim Berners-Lee probably did not anticipate that one endpoint would succesfully fake being the entire universe.
The deeper question is, do we want the shape of digital networks to reflect the observed concentration or real current social and economic networks or do we want to use the leverage of this new techology to shape things in a different (hopefully better) direction?
The mess we are in today is not so much failure of technology as it is digital illiteracy, from the casual user all the way to the most influential legal and political roles.
Here is a book on the topic - Compliance Industrial Complex;
https://www.amazon.com/Compliance-Industrial-Complex-Operati...
It's about anti-policies (anti hate, anti money laundering, etc.), securitization of governance (private companies create and enforce what should be law) and pre-crime, using technology to do this instead of addressing underlying social problems.
Are those the major issues of today? Those are the major issues for censors, not for communicators.
They have hundreds of servers running today by volunteers, there is little cost of entry since even cellphones can be used as servers (nodes) to keep you private notes or keep the notes from people you follow.
There is now a file sharing service called "Blossom" which is decentralized in the same simple manner. I don't think I've seen there a way to specify custom domains, people can only use the public key for the moment to host simple web pages without a server behind.
Many of the topics in your page are matching with has been implemented there, it might be a good match for you to improve it further.
The answer is yes.
NOSTR is similar to emails. They depend on nostr/email providers and aren't depending on any single of them, what exists is a common agreement (protocol). The overwhelming majority of those providers are free and you can also run your own from the cellphone.
Some providers might become commercial like gmail, still many others will still provide access for free. Email is doing just fine nowadays, NOSTR will do fine as well.
E.g. ActivityPub has exactly the same claims, and it's currently handling several million, essentially all interactable. Some parts are working fine, and some parts are DDoSing every link shared on any normally-connected instance.
Contrast this with e.g. Secure Scuttlebutt (under a normal setup). Adding more people to the connected graph (implying also a more densely connected graph) means exponentially more traffic and more storage for each member, due to the friend-of-a-friend proxying built in. It doesn't take long at all to reach the point where a normal internet connection can't keep up, and you fall farther and farther behind.
Mastodon falls somewhere in between - adding servers mostly splits load when you add instances, but caching behavior grows linearly and tends to happen simultaneously ~everywhere, and it doesn't take long before it's beyond what hobbyists can handle. It even affects outsiders, due to preloading link previews, which is a core privacy decision that's arguably part of the protocol.
Where does nostr fit in? Because "a protocol" describes ^ all of those. It's a mostly meaningless descriptor, beyond "probably not tied to a single company" (but not more than "probably").
NOSTR is the same as Email on that regard. You push a note to the destination (relay) and adding more destinations doesn't increase the load, it splits the load.
There is no centralization at NOSTR, there is no mandatory record of who sends who and what. It is just like email, send it over and let the receiving parties do whatever they want with it.
In fact, it goes beyond email to the point that you can write a NOSTR note on a piece of paper and still be certain that the note was written by a specific person and is unmodified.
>NOSTR is the same as Email on that regard... [etc]
This is useful information :)
2. Proof of work time IDs as timestamps: This doesn't work. It's trivial to backdate posts just by picking an earlier ID. (I don't care about this topic personally but people are concerned about backdating not forward-dating.)
N. Decentralized instances should be able to host partial data: This is where I got lost. If everybody is hosting their own data, why is anything else needed?
And one can host many signing keys at a single domain.
I believe I have the timeline right that this study happened not too long before StackOverflow got the idea that getting upvoted gives you ten points and downvoting someone costs you two. As long as you’re saying something useful occasionally instead of disagreeing with everyone else, your karma continues to rise.
I don’t recall if any of the signatures sign across any other signatures. I think in some cases it’s just a… Merkle List?
Merkle trees get weird if they’re done as signatures. With bitcoin everyone votes on the validity in a fairly narrow timeframe and the implausibility of spoofing a record and then spoofing the next n is what allows for the trust-in-the-blind to be practical (even if I don’t agree that the theory is sound).
For signatures, on data at rest, it gets complicated. Because at some point you’re trusting a payload that has signatures from expired certificates. You end up having/needing transitive trust, because the two signatures you care about are valid, and they signed the payload while the signatures they cared about were still valid. So now you need to look at signature timestamps, Cert validity range, Cert chain validity range, CRLs or OCSP, and you better make sure all your timestamps are in UTC…
It’s easier if the system has a maximum deliver-by date, and you just drop anything that shows up too out of band. I can use a piece of software that was created and signed over a year ago, but maybe I shouldn’t accept year-old messages.
I did a code signing system for avionics software, that supported chain of custody via countersigning (Merkle before anyone heard of bitcoin). The people who needed to understand it did but it broke some brains. I lost count of how many meetings we had where we had to explain the soundness of the transitivity. People were nervous, and frankly there weren’t enough people watching the watchers. Sometimes you only catch your own mistakes when teaching.
Regarding hosting partial data: there should be an option to host just recent data for the past month or other time frames and not full DB of URLs. This would make decentralization better as each instance could have less storage requirements, but total information would be present on the network.
- Propagation (via asynchronous notifications). Making it more like NNTP. Though perhaps that is not very different functionally from feed (RSS and Atom) aggregators: those just rely on pulling more than on pushing.
- A domain name per user. This can be problematic: you have to be a relatively tech-savvy person with a stable income and living in an accommodating enough country (no disconnection of financial systems, blocking of registrar websites, etc) to reliably maintain a personal domain name.
- Mandatory signatures. I would prefer OpenPGP over a fixed algorithm though: otherwise it lacks cryptographic agility, and reinvents parts of it (including key distribution). And perhaps to make that optional.
- Bitcoin blockchain.
I do not quite see how those help with decentralization, though propagation may help with discovery, which indeed tends to be problematic in decentralized and distributed systems. But that can be achieved with NNTP or aggregators. While the rest seems to hurt the "Simple" part of RSS.
but it came right at a time when the industry had kind of just stopped listening to that whole group, and it was built on multicast, which was a dying horse.
but if we had that facility as a widely implemented open standard, things would be much different and arguably much better today.
There's a fascinating research project Librecast [0], funded by the EU via NLnet, that may boost multicast right into modern tech stacks again.
Isn't multicasting something already available with UDP or Point-to-Point connections without a single network envolved?
The other big one is access. If we call agree on multicast semantics and addressing, and its built into everyone operating system, then we can all use that as a equal access facility to effectively publish to everyone, not just people who happen to be part of this particular club and are running this particular flavor of multicast.
The other issue is who's going to host it? I need a port somehow (CGNAT be damned!).
Usenet doesn't scale. The Eternal September taught us that.
To being Usenet back into the mainstream would require a major protocol upgrade, to say nothing of the seismic social shift.
I don’t think it’s a fruitful or useful comment to say something is “like Usenet” as a dismissal. So what if it is? It was useful as hell when it wasn’t terrible.
One area that is overlooked is commercialization. I believe, that the decentralized protocol needs to support some kind of paid subscription and/or micropayments.
WebMonetization ( https://webmonetization.org/docs/ ) is a good start, but they're not tackling the actual payment infrastructure setup.
The project's main differentiating factor seems to be not propagating the actual content to the nodes but instead save disk space by only distributing hashes of content.
However, having a "p2p" decentralized network of hashes doesn't solve the "discovery" problem. The blog lists the following bullet points of metadata but that's not enough to facilitate "content discovery":
>However it could be possible to build a scalable and fast decentralized infrastructure if instances only kept references to hosted content.
>Let’s define what could be the absolute minimum structure of decentralized content unit:
>- Reference to your content — a URL
>- User ID — A way to identify who posted the content (domain name)
>- Signature — A way to verify that the user is the actual owner
>- Content hash — A way to identify if content was changed after publishing
>- Post time — A way to know when the post was submitted to the platform
>It is not unreasonable to expect that all this information could fit into roughly 100 bytes.
Those minimal 5 fields of metadata (url+userid+sig+hash+time) are not enough to facilitate content discovery.
Content discovery of reducing the infinite internet down to a manageable subset requires a lot more metadata. That extra metadata requires scanning the actual content instead of the hashes. This extra metadata based on actual content (e.g. Google's "search index", Twitter's tweets & hashtags, etc) -- is one of the factors that acts as unescapable gravity pulling users towards centralization.
To the author, what algorithm did you have in mind for decentralized content discovery?
As far as I can tell it is stuck in some sort of inefficient prototype stage. which is unfortunate because I think it is one of the neatest most compelling parts of the whole project. it is very cool to be able build protocols with no central server.
Here is my prototype of a video streaming service built on it. I abandoned the idea mainly because I am a poor programmer and could never muster the enthusiasm to get it past the prototype stage. but the idea of a a video streaming service that was actually serverless sounded cool at the time
http://nl1.outband.net/fossil/ipfs_stream/file?name=ipfs_str...
> In RSDS protocol DID public key is hosted on each domain and everyone is free to verify all the posts that were submitted to a decentralized system by that user.
DNS seems far too easy to hijack for me to rely on it for any kind of verification. TLS works because the server which an A(AAA) record points to has to have the private key, meaning that you have to take control of that to impersonate the server. I don’t see a similar protection here.
It took me 20 years to decide maybe they were right. A bunch if Reddits more tightly associated with a set of websites and users than with a centralized ad platform would be fairly good - if you had browser support for handling the syndicated comments. You could have one for your friends or colleagues, one for watchdog groups to discuss their fact checking or responses to a new campaign by a troublesome company.
Yeah, this won't work. Like at all. This idea has been tried over and over on various decentralized apps and the problem is as nodes go offline and online links quickly break...
No offense but this is a very half-assed post to gloss over what has been one of the basic problems in the space. It's a problem that inspired research in DHTs, various attempts at decentralized storage systems, and most recently -- we're getting some interesting hybrid approaches that seem like they will actually work.
>Domain names should be decentralized IDs (DIDs)
This is a hard problem by itself. All the decentralized name systems I've seen suck. People currently try use DHTs. I'm not sure that a DHT can provide reliability though and since the name is the root of the entire system it needs to be 100% reliable. In my own peer-to-peer work I side-step this problem entirely by having a fixed list of root servers. You don't have to try "decentralize" everything.
>Proof of work time IDs can be used as timestamps
Horribly inefficient for a social feed and orphans are going to screw you even more.
I think you've not thought about this very hard.
Not author, but that is what the global domain system is. There are a handful of root name servers that are baked into DNS resolvers.
Only in decentralized systems. In centralized ones, fake timestamps down to the bit all over the motherfucking space. So, basically, quasi, ultimately, so to speak, time and order don't matter in centralized systems, only the Dachshund does.