Redecentralize.org
redecentralize.org
redecentralize.org
Even trying to explain federation to my work colleagues who are in the industry is difficult, because it is such a fundamental shift from the normal web infrastructure.
You have your server, and it relays messages back and forth to other people’s servers for you.
Part of the point that I'm trying to make is that e-mail as it stands today - with the majority of messages going through the servers of a single corporation - isn't all that decentralized in practice.
When you mention e-mail to the layperson without additional explanation, what they have in mind is a fairly centralized system.
Let’s say you make a social network that people don’t need to know is decentralized. It’s easy to use! Cool, well anyone who has tried to launch a centralized social network will tell you that getting market share is very difficult. A good UX is necessary but not sufficient... you need to outcompete the centralized incumbents. If the decentralized design helps (maybe people like censorship-resistance), then you could succeed. If it doesn’t — and perhaps makes development more difficult — then you are much less likely to gain adoption.
Any entirely uncensored service seems like it would be overrun by scammers, and griefers of all kinds.
As for scammers, imagine something like twitter. If I follow my friends and celebrities I like, scammers will be relegated to the comments section of their tweets (I wouldn't see their actual tweets because I wouldn't follow a scammer). Then you could use some kind of web of trust system to filter the comments - perhaps I would only request comments for people I'm following, or people followed by people I'm following, etc.
It fail when it's a push instead. That would be anything that have suggestion, any public conversation, like a forum, or twitter, even private conversation in some case, like an email service, etc...
For sure you won't pull what you don't want, that's by definition, but you moderation is needed for the push system, where you don't control everything that goes to you.
Most service are push too, we want things to be suggested, we don't always know exactly what we want, we don't know even if it exist.
The problem is that before any of that matters, assuming your goal is mass adoption beyond narrow niches of the already interested, you need to convince people they should care. This is fundamentally marketing and sales, which are the sorts of efforts many people trying to build these things are actively disdainful of. Moreover, who is the messenger to public? The very same decentralization that makes these sorts of solutions interesting actively works against the sort of marketing and sales activities that would get the non-initiated engaged.
Fragmented, uncoordinated, and probably just word-of-mouth messaging against well coordinated, well budgeted, and financially motivated opposing interests seem to me to be the bigger hurdles to overcome than assembling the right software or protocols.
[1] https://en.wikipedia.org/wiki/Distributism [2] https://en.wikipedia.org/wiki/Subsidiarity
Wonderful malapropism.
Add to this that decentralisation introduces engineering challenges that centralisation doesn't and it's abundantly clear why fee decentralised projects work.
For my money, I've always believed the right way to make the internet communal again is about ownership, not protocols. I'd much rather be a member of a cooperative messaging app than struggle through the technical issues of a decentralised one. Even if it meant Wikipedia style begging once a year. But that's just me.
- earning money for sharing resources (drive space, cpu cores) with the network - 1 time cost for storing a file (possibly eternally) vs the current recurring subscription - only 1 password needed to access the network vs the current way of every site needing a separate password
bear in mind its not even finished so maybe these things won't happen in the end
So here is a very compelling use-case for people who don't care. Sadly it conflicts with the interests of the device maker duopoly.
It's a massive pita for reliable consumer VoIP.
Has that been true for very long? It seems like nowadays it is trivial, but a decade ago it was extremely common for users to have to do manual port forwarding to receive connections.
As for VPSs, that's basically a non-starter in terms of user experience, similar to the issue you raise with p2p software. For the audience of HN, NAT etc. are a non-issue, but for real democratization to occur, the process needs to be as simple as "install app, run app, share link provided by app to friends".
The point about VPSs is that extra public IPs have been easily available. If simply being able to receive incoming connections was sufficient, the process of setting up a VPS would have been easily automated. In reality, server-based protocols such as HTTP/DNS are insufficient for decentralization, and developing replacements takes work.
That seems to be true but I’m unsure as to why. What’s your take?
2. Even worse, the single authority is bound to a single (logical) authoritative server.
Using pubkeys for names, like Freenet or IPNS, solves (2) but not (1). Which does allow content to be wholly retrieved from peers (a massive step up!), but still relies on a single authority. So I would think that well-known authorities will still crop up, centralize, and abuse market inefficiency. Although much easier to fork, so more pressure to behave (imagine being able to say hey use my faceboot alternative at http://newsite.com, and have all the content automatically there, without the hostile software!).
I've been thinking about this for quite some time, and ideally (1) would be solved as well. The only system I've seen in the wild that attempts to distribute authority itself is Camlistore's "claims". But the idea being that a "far" link should truly be changeable by the end user, rather than to a singular authority.
Someone noted that the forums are Google Groups and the site, blog etc. are hosted on Github. Shouldn't dog-fooding inherently be part of this strategy?
This makes sense. But it's a catch-22.
Might not be enough to switch for if you're already happy with what you use for RSS, but I think it's a great feature.
Edit: No new videos on their youtube channel younger than 3 years, either.
Just hit 19M+ monthly users.
In production with Internet Archive, HackerNoon, etc.
( https://github.com/amark/gun )
Scaling systems that have to run out of the browser by default is tough, but we're doing this on $0 in server costs, in javascript, with millions of users.