Live data from Hacker News

Ask HN: When is federation a better solution than decentralization?

news.ycombinator.com

51–60 of 82 posts

Re: Ask HN: When is federation a better solution than decentralization?

#51
post #48

Blockchains were designed to prevent double-spending, and not to solve other problems. Most blockchain enthusiasm is misplaced. One subjective (but powerful) reason for blockchain implementations, is that we're all human, and our egos want to avoid making someone else's database The Big Platform. Or maybe that's our rational sense (looking at GOOG/FB), we don't want our application controlled by someone else. This ar…

We have seen a 51% double spending attack on Bitcoin Gold just a few days ago. Can we stop claiming that blockchains prevent that?

The attacks on the smaller blockchains are good news. Blockchains have the biggest bug bounties in history, and in time we'll all learn what works.

I've never heard anyone claim blockchains are immune to double spending. There's evolutionary value behind all the experiments. And they're all experiments, including Bitcoin.

Re: Ask HN: When is federation a better solution than decentralization?

#52
Agreed. Federation makes a lot of sense to me in many cases, especially those that relate to the enterprise use cases where performance over extreme theoretical security is much more critical. I think some newer consensus algorithms are experimenting with similar concepts as well. For instance, with delegated proof of stake, you can use your funds to elect a federation or a government (a list of nodes), which in turn will stake their funds and resources to validate blocks.

Re: Ask HN: When is federation a better solution than decentralization?

#53
As someone who has worked exactly with these issues for the past 7 years, let me share what I have learned.

Just a bit of background. My first startup, https://qbix.com focused on letting each community host its own social network, the same way Wordpress powers blogs. Wordpress powers 30% of the Web so it seemed to be a good business model (and it is). Here is a video explaining that: https://www.youtube.com/watch?v=pZ1O_gmPneI

Last year we started a new company at https://intercoin.org focused on letting each community manage its own currency. We saw that crypto wasn't solving payments as well as WeChat and all the other centralized social networks, so we figured we could fix that. Here is a video explaining that: https://www.youtube.com/watch?v=HIbAz29L-FA

OK, so what have I learned?

First of all, federated is much easier. You simply have one source of truth for each stream of data. It's why it's more prevalent. It also creates "landlords" that you have to trust to host your data, and often their agendas clash with your own. Two months ago I asked why have "communities" at all: https://news.ycombinator.com/item?id=16741913

We are familiar with "landlords" all the time, and their inordinate power within their ecosystems. Consider Amazon's bookstore, Apple's app store, Google's search engine, Facebook's social network, and so on. Federating this would be a very good way of introducing choice, and competition among landlords. You still have to choose a landlord, but now the market can improve everyone's experience through competition.

But it turns out that you can do even better than the market, if you build technology that facilitates collaboration instead of competition. Collaboration has entirely different economics, but ultimately wins in the end. Think about Wikipedia vs Britannica, Linux vs Windows, WebKit vs old IE, and so on.

With Collaboration, the infrastructure gets paid for, but not by extracting rents through closed source software. Instead, you distribute the work across many different actors and none of them own their own little fiefdom but they are all intermixed in a grand tapestry. So why would any actor do anything? One answer is that, if they don't do it, someone else will, so they get a little bit of control / money in the beginning, which fades with time. That part is similar to capitalism. But another part is simply because "the main software is designed to facilitate that mode of collaboration by default".

Also the landlord can be a single point of failure for your data. Consider, for instance, how we store files. Imagine you have no backups in the cloud, and all files are stored in your apartment. Now there's a fire. What happened to all your files? They are gone.

But if your'e going to have backups in the cloud, you want to make sure they are encrypted, and only you can access them. Even better would be to blur the distinction between servers run by "the landlord" (even if it's your own apartment) and "the cloud" and just make protocols that find the best server, have it be in a consensus group, encrypt everything end-to-end, and allow reading and writing by multiple parties.

This is very hard to get right. But any such platform would allow people to build communities on top of a reliable foundation, where only members in the communities would be able to access information, and they could have validators who vouch for what actions (e.g. in a game) are valid. Clients that don't agree with a validator can ignore it, and thus the consensus may sometimes split (e.g. a hard fork), with each client choosing which validator to listen to.

This is a strict improvement in terms of resilience and control, removing arbitrary landlord relations, and capable of reducing back to them as a special case. It's just harder to implement.

Consider, for example, why we have domains and DNS. I have files, why do I have to "choose Google Drive" to store my data, and then trust that they will store it, encrypt it, and so on? Why do we have to choose a domain at all? There is a technique called Kademlia, invented in 2002, which was used to power DHTs including BitTorrent and now used in SAFENetwork. SAFENetwork is probably the ultimate example of a benign "landlord" - a network which encrypts and stores your files redundantly, and prevents them being taken down. (Qbix is moving towards the same thing (https://qbix.com/blog) except with dynamic data instead of static files.

https://maidsafe.net/docs/Safe%20Network%20Primer.pdf

I would say the future is:

  End-to-end encryption
  Kademlia (or similar) for routing
  Consensus groups for each data stream
  Churn (backend groups constantly change to prevent collusion)
  Proof of resource (every so often, within groups)
On top of this, people can build apps that can spread phone-to-phone, taking advantage of a dynamic data layer that lets anyone start their own "stream" and not worry about the arbitrary decision of "which domain hosts it". The participants get determine the rules of each stream (democracy? dictatorship?) and the landlord is just someone they give access to as well. A search engine would just be a guest in many streams.

Do I think Federated systems and market mechanisms are great? Yes. Do I think Distributed systems acting as totally benign landlords are better? Oh yes!

They are more resilient, too. For a crypto-currency, that is a must, or you can have this: https://www.youtube.com/watch?v=E1d5VvCa8Fo (they who know this movie know what happened there.)

But they are way harder to do. It took us over 1 year at Intercoin just to come up with the right design. If you want to know more about this topic, you can read about our design decisions (and economics etc) here:

https://forum.intercoin.org/

Also feel free to email me (greg is the username, intercoin.org is the domain) if you have more questions or want to discuss this topic, I geek out on it. Here is a video I made about decentralizing more than just software:

https://www.youtube.com/watch?v=WzMm7-j7yIY

Re: Ask HN: When is federation a better solution than decentralization?

#54
post #29

Earlier quoted context omitted.

Marketing, marketing, and amount of money that goes into that development. Give me a few thousand developers, a multi billion dollar ad budget, and the ability to signup every facebook user on the planet to my messaging service, and I'll also win against XMPP. In fact, with those resources carrier pidgeons would've won against XMPP.

This doesn't explain why IRC can't compete with Slack or the other corporate messaging services. Slack was a side project by a failing game company. Its growth was largely organic. I think the original premise is right that user experience is more important than ethics or philosophy or whatever the heck it is we're talking about when federations come up

IRC didn't by even have anyone trying to improve stuff until the IRCv3 WG came along, and now we're seeing massive innovation and adoption in short timeframes.

Re: Ask HN: When is federation a better solution than decentralization?

#55
post #54

Earlier quoted context omitted.

This doesn't explain why IRC can't compete with Slack or the other corporate messaging services. Slack was a side project by a failing game company. Its growth was largely organic. I think the original premise is right that user experience is more important than ethics or philosophy or whatever the heck it is we're talking about when federations come up

IRC didn't by even have anyone trying to improve stuff until the IRCv3 WG came along, and now we're seeing massive innovation and adoption in short timeframes.

[deleted]

Re: Ask HN: When is federation a better solution than decentralization?

#56
post #8

Earlier quoted context omitted.

Yeah, but moxie is mostly wrong. He's only seen worst-case scenarios and assumes everything is lile that, so he builds his centralized stuff instead. You can easily move forward with a federated protocol as well if you've got cooperating people, guarantee only 6 months of support for a protocol version, and have a versioning and feature flag system. Hell in one project I contribute to we've kept protocol compatibilit…

If he's wrong and it's easy, why can no one do it? Why did Slack overrun IRC? XMPP left by the wayside by Google and Facebook? Because it isn't easy, and users will always value the experience over compatibility and principal.

One thing I think some people got it wrong: Decentralization is not a feature, it's a method.

(Most) Users won't care whether or not they are using something decentralized, they only care what they can achievement with that software/service. Is it doing better than others on the market?

Back to the topic, about why Slack defeated IRC & XMPP: A product -- whether or not it's a online service or a hardware -- needs to keep up with the world. For example: If one day, people started to sharing photos and videos and voices during their online chat session, and your software can't keep up with that, then you will likely loose those people soon enough.

Currently, centralized software made upgrading very easy. You have all the control you need to force users to upgrade to your newer and richer client. While in the decentralized world, you may need to beg somebody to upgrade their server to support the newer version of your client (Due to that, you may not dare to upgrade your product that often).

Also, decentralized software usually hard to develop, while harder to generate enough revenue to be commercialized or be profitable. When clever people needs to survive, they will save the trouble and feed themselves (make money) first.

I'm not saying work on something decentralized is a bad idea though, we need decentralized service in today's very centralized world for sure. But make sure you can deliver the same level of experience (or be better) of your centralized competitors, then maybe people will start to use it.

Re: Ask HN: When is federation a better solution than decentralization?

#57
post #7

About federation in particular: Moxie wrote about why Signal is unfederated a little while back: https://signal.org/blog/the-ecosystem-is-moving/ It has some interesting insights into when federation works and when it doesn’t. “Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is poss…

It's good to compare this with views on the other side: https://gultsch.de/objection.html

Re: Ask HN: When is federation a better solution than decentralization?

#59
post #49

Here's the core of the problem and also why most of crypto / blockchain technology will go down the drain soon: Decentralization isn't a business model. The opposite is. That's it. How you get to any competitive edge in a market is: 1) Be better than your competitors in a field. 2) Own that field and displace everyone else. 3) Extract value. The Crypto hype happened because a super elegant technical solution (-> Bloc…

Your argument against crypto is one of the more compelling I've read. I like the "deep local optimum" visual you painted. I definitely agree if you're comparing "crypto" directly to centralized companies doing traditional things -- they're not going anywhere. However, I think it solves a different problem. It's a geopolitical problem. Blockchain technology provide a bulletproof (so far) way of exchanging value across…

But currently this only works in third world countries where the government lacks resources or care to combat it. Plus their is still a middleman if you don't mine the cryptocurrency yourself. I still have to pay a exchange if I cannot find someone willing to take cash/check from me. You also have the opposite effect where you need the exchange and a bank account to turn that coin I sent into usable cash.

Re: Ask HN: When is federation a better solution than decentralization?

#60
post #19

The problem with a lot of federated platforms (I’m thinking of diaspora, secure scuttlebutt, mastodon etc) is that whole they do provide a way for data to be easily synchronized and replicated, they never answer the question of who is ultimately going to store the data and why. So you end up with a “temporary” list of servers for new users to sign up with, which become centralized in their own right.

SSB is distinct from Diaspora and Mastodon in this respect. It's decentralised rather than federated (pub servers are just peers with a public address).

SSB's answer to this question is: your friends are going to store your data, because they want to read it themselves. You are going to store your friends' data, because you want to pass it on to your other friends.

Post reply on HN