Hacker News new | past | comments | ask | show | jobs | submit login
Scuttlebutt, a Decentralized Alternative to Facebook (inthemesh.com)
623 points by bpierre on Apr 19, 2018 | hide | past | web | favorite | 342 comments



I think it's fascinating to see distributed social networks from a tech perspective. From what I've seen so far they exacerbate the problems that Facebook has been seeing so much backlash against.

1. The whole Cambridge Analytica issue was caused by APIs that are too open. For distributed systems there are more ways to exploit the APIs and gather data on users.

2. There is a clear issue with Facebook's accountability in these areas. Distributed systems are typically open source, they run on multiple servers by different owners, this leads to zero accountability.

3. GDPR compliance about deleting data is almost impossible in a distributed system.

4. Some of the problems with Facebook are more about usability and clarifying how things work to users. For instance the scandal with people giving away access to their private messages. Open source software and distributed software tends to be much harder to use.

5. Any future concern/issue will be much harder to resolve if there are thousands of different instance running decentralized social networks.

6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data. So it becomes harder to address those concerns in a distributed setting.

So while I think this stuff is awesome from a tech perspective, in many ways it just makes these problems harder to solve.


I think your post hints at a general schizophrenia in the latest, culture-war-fueled push against Facebook. On the one hand, the public debate is still significantly dominated by the old guard of anti-Facebook activists, whose objectives can be summarised as "Facebook's power over its users must be reduced". On the other, the renewed interest in doing /something/ about Facebook in the wake of Cambridge Analytica and fake news (and, before that, cyberbullying, stalking, harassment...) essentially amounts to "Facebook's power over its users must be exercised to quell evil". More often than not, the two are actually diametrically opposed (as when quelling evil turns out to require an increase in power). A hypothetical actually usable decentralised social network would advance the former cause, and, as you pointed out, set back the latter.


I think grandparent's point was that the first cause you mention - reducing FB's power over users - does nothing for the users if this power instead goes to other 3rd parties, and perhaps even grows.

GP points out that in a distributed social network, 3rd parties can still mine your data, you still have trouble permanently erasing information, and in fact these problems grow instead of shrink. From a user's POV, what matters is the total amount of 3rd parties over them and the leverage they have against these 3rd parties as a whole. GP's point is that shrinking FB's power by going to a distributed social network might actually increase the total power 3rd parties have over users.


I'm in the "facebook should have less power" - camp and I'm not worried about those 3rd parties if they are not unified. The amount of 3rd parties does not matter at all.

I'm not afraid that I do something stupid and people find out. I'm afraid that I don't do anything stupid, but facebook makes it look like I did. They have authority a distributed system could never have.

Also I'm not worried about someone who sells pruning shears could mine my data and find out that I like pruning shears. I'm worried that facebook only shows me adds of shitty pruning shears of certain companies. Who happen to be drinking buddies with facebook executives.

You can say that these are delusional things to worry about. But how do you draw the line when concentration of power is OK and when it's not?


Those who are concerned about this have three options:

* make the effort to learn how to set up and maintain your own instance of your chosen federated social app. You get to decide exactly what data is and isn't shared with the network. You don't depend on the goodwill of any third party , or their security competence (just your own).

* find a geek you know, and get them to host an instance for you. There is a third party, but it's someone you personally know and presumably trust.

* find a public instance run by a collective or organisation you trust to care about your privacy and know how to protect it, eg some people might trust the motives and competence of EFF, or their country's civil liberties organisation (eg ACLU in the US), or a collective like RiseUp.net or Disroot.org.

While export/ import of accounts between instances is an unsolved problem at present (Hubzilla can do it using Nomadic Identity but only between Hubzilla instances), the devs of all the federated apps are aware of it as a major pain point, and work is underway to implement it. In the meantime, if you're willing to go to the trouble of re-following and nagging all your followers to re-follow, you can move between the 3 options above at will. FB and other datafarms offer you none of these options.

EDIT: formatting


It's not as binary as you make it seem; It's more a question of oversight than it is power.


> The whole Cambridge Analytica issue was caused by APIs that are too open. For distributed systems there are more ways to exploit the APIs and gather data on users.

Huh? Scuttlebutt is fully encrypted.. doesn't that make the API vastly more locked down than Facebook/etc?

> There is a clear issue with Facebook's accountability in these areas. Distributed systems are typically open source, they run on multiple servers by different owners, this leads to zero accountability.

This is no worse than Facebook though. With Facebook, your friend could steal all of the data you let them see. With Scuttlebutt, your friend could steal all of the data you let them see.

At least with this I control who sees my data, no? Sure, I can't have accountability with a friend, but at least no company/etc has access to my data.

> GDPR compliance about deleting data is almost impossible in a distributed system.

Doesn't GDPR apply to companies? If my mom sends me a physical card, do I have to adhere to GDPR laws with her address/name? How is that any different than Scuttlebutt?


> Scuttlebutt is fully encrypted.. doesn't that make the API vastly more locked down than Facebook/etc?

Encryption has nothing to do with it. The whole issue with CA was that they (just as many apps before them) were using Facebook social graph data that was available for them to access via the API. Encryption on any layer has nothing to do with it - if you have access to the API, you get the data. In distributed system, if you are a node in the system, you have to have access to social graph data - otherwise the whole concept of social network does not work. You can't "see what your friends are doing" if there's no information about who your "friends" are. And if the nodes on the network have information about who your friends are - or can get that information - then they have the same access as CA (and many other apps before them) had. Facebook can at least (if they wanted to) cut off the external API and not tell the social graph structure to anybody outside Facebook. I don't see how this is possible in a distributed network.


You very definitely don't need to expose the social graph to the api. We are doing exactly that in Peergos [1][2]. Your social graph is only stored in encrypted form in your own storage space (in IPFS). The source of a follow request can't be deduced by anyone except the recipient.

If you start integrating Tor/i2p hidden services, even global passive network adversaries will struggle to figure out the social graph from network monitoring.

[1] https://github.com/peergos/peergos

[2] https://peergos.github.io/book


If the recipient can access it, then the recipient can grant access to a third party- which is what happened with Facebook/CA. People unwittingly shared the information their friends had shared with them with a third party.


That is clearly fundamentally true of any information. The question is what is shared by default. We don't even share your friend list by default, so the exposure is much less.


Default are powerful, but you are always one "Please click this to enable new exciting ways to play Candy Crush" away from any non-default setting. It may be true that FB users value their privacy, but reflecting these values in minute-to-minute behavior is a much more complex question. People are not always vigilant or realize what exactly is the consequence of their actions.


From what I understand, in Peergos the friend list is stored on certain node. Which means software running on that node can see your friend list - which is essentially what happened in CA case, except maybe Peergos does not allow to run third-party apps on private node, but even if they didn't currently, I see nothing preventing from this happening in the future. What happened in CA case, AFAIK, is that users allowed the software to access their social graph data, and that software compiled it into a database that was used for purposes the users didn't intend to. If we assume that the users can run third-party plugins on a Peergos node, why isn't that possible with Peergos?


Nope. Nothing (apart from your username, which is public) is ever stored unencrypted anywhere. Even your own Peergos server can't see your friend list. It is decrypted by your client when you log in.

We don't currently allow third party apps in Peergos, and when we do they won't be able to access the social graph, nor will they be able to connect to the internet, nor anything else outside peergos. So that data can't be exfiltrated.


Scuttlebutt is not at all "fully encrypted", it's fairly trivial to spider and download just about everything. The hardest part is the first foothold (which can be found posted various places, including the official docs on ssb), from there, downloading the entire "social web" it has can be done with the "main client" by basically changing a single config value.


I haven't looked into the protocol in any depth yet but it does seem like it supports end-to-end encrypted updates.

What data are you talking about that can easily be crawled without any permissions?

If it is that simple then maybe Scuttlebutt isn't a good protocol, but a secure end-to-end platform like this is definitely possible. And if anyone is going to build it it's not going to be a company who makes all of their cash from harvesting user data.


I've written a partial implementation of the scuttlebutt p2p protocol (not the encryption, but everything on top). While point to point is encrypted, the bulk of the data is not encrypted. You can specifically send "private" messages that are encrypted such that only a set of keys (users) can decrypt (read) them, but this is by no means the default for anything.


So the feed is public like Twitter?


essentially public, and also basically requires downloading and storing the entire history of a "feed" to verify it.


Sure you can download everything, but you can't read it...


you can read 90+% of it (only specifically private messages are unreadable, and most of the systems are not built on those)


It's worse than facebook because there's no one to have responsibility to be accountable. This ties in with your question about GDPR. While I'm not a lawyer, as far as I know it doesn't matter if you're a person or a company, if you're collecting data, it's something you can be liable for. So in a distributed system, all parties who maintain the data sources would be liable. I actually wonder how this works logistically in terms of storing account info on something like Ethereum.


> It's worse than facebook because there's no one to have responsibility to be accountable.

I guess I just don't understand what accountability there is to be even had? If I send an encrypted message to my friend, who is accountable? What are they accountable for?

If I'm sending illegal content to someone only I can be held accountable (and possibly the person I'm sending to). Is that any different in Scuttlebutts case?


Ah i think i may have misunderstood how the system is made. It is purely peer to peer. So any issues could be if the software has a security vulnerability, but I'm not sure how that ties in with things like "as-use" open source licensing. This post explained the network fairly well I found: https://staltz.com/an-off-grid-social-network.html

As far as GDPR goes, you're right because you're specifically choosing people to send it to. However, having a mechanism to delete your messages on other people's systems when they sync would probably go a long way.


Are you claiming that GDPR holds individuals liable to delete info they might have about another person on request?


Only if they are using that data in a professional or commercial activity.


> having a mechanism to delete your messages on other people's systems when they sync would probably go a long way.

It is my understanding at the moment that it's not scientifically possible to do this. If I'm mistaken I would love to hear a proposal for doing this, but I don't understand how full read access can be revokable once you have the data and a way to decrypt it. DRM doesn't count/work.


Not technically possible currently (well, last I checked). A client could be configured to send a "please delete message id 29342" type post, but other clients would have to know how to understand that and to honor it. The functionality would be similar to "sender has recalled this message" in exchange.

Also, the way the protocol works is that clients discover the most recent log entry number, and then request all "missing" ones. So that delete message would be more like a "please overwrite message id 29342 with zeros or something".


Is it possible to do revocable private messages in a decentralized system. My understanding it that the Zot protocol (used by Hubzilla) deals with this by keeping private data on the hub of the user sharing it, while public message can be mirrored to the hubs of any users receiving it. "Sending" a private message (or media file) to another user actually sends a notification to that user that they have permission to access it. When the receiver wants to access the message, their hub has to correctly identify them to the sender's hub, using credentials sent as part of that notification. But all of that is handled in the background, not a painful, confusing manual process users have to know about. See: https://github.com/friendica/friendica/issues/2894#issuecomm...

From what I understand of SSB,it works by distributing messages to receiving users as part of a blockchain, making all messages effectively public, even if not published with the goal of giving the public access. But maybe similar functionality could be added by setting up private "clubs" - pub servers set up by groups of users who know and trust each other - which would play the same role as a Hubzilla hub, storing private messages and displaying them to users who can authenticate correctly.


>It's worse than facebook because there's no one to have responsibility to be accountable.

Yeah, it is worse because if you screw up, you don't have anyone to blame but yourself.

You have complete control over your data.


It is no worse than email is now. In fact, it's better because only allowed clients can read messages authorized for them.


True for 1to1 messages, everything else is stored in plaintext and public.


> Scuttlebutt is fully encrypted.. doesn't that make the API vastly more locked down than Facebook/etc?

No, not at all! TOR is fully encrypted, but there are somewhat regular vulnerability reports about various parts of the stack. Including criticial vulnerabilities that can and have been exploited by nation states, for example.

> This is no worse than Facebook though

This is not at all clear to me. The attack surface for Scuttlebutt is much larger, and I trust Facebook's security team to audit and patch much more than I trust any random friend.


> I trust Facebook's security team to audit and patch much more than I trust any random friend.

Sure, but I wouldn't choose "a random friend" to run my FB replacement service, I'd choose a trusted friend. And more importantly, no matter how good Facebooks security team are at patching and auditing servers - THEY ARE THE ADVERSARY IN THIS CONTEXT!


> Sure, but I wouldn't choose "a random friend" to run my FB replacement service, I'd choose a trusted friend.

How does this relate to scuttlebutt? There's no scuttlebutt “service”; it's a tool and a protocol, like a pen and the English language.

> no matter how good Facebooks security team are at patching and auditing servers - THEY ARE THE ADVERSARY IN THIS CONTEXT!

I think this is the salient point: if you send data to your friend, they necessarily have that data and can leak it; but there's no need for a stranger with unknown motives (Facebook) to also have that data.


> This is no worse than Facebook though. With Facebook, your friend could steal all of the data you let them see. With Scuttlebutt, your friend could steal all of the data you let them see.

Your friend can, but Facebook can scrutinize third-party apps. In a decentralized world, there's no one who has access to holistically examine automated access and detect shady activity. In a decentralized world, everything is essentially a third-party app.


Do apps really bring that much value to the social network experience? I know for myself I have not found a single Facebook app that brings any positive value to my life.


Have any of your friends installed a Facebook app? Because it doesn’t matter if you decide they're not worth using, you have to make sure nobody in your network uses them either.


A lot of people like using them as a login system. Maybe WebAuthn will help with that since it’s a valid use but most people didn’t see what else they were agreeing to.

The other thing I’ve seen a lot of people use are notifications / invites. e.g. most big gaming communities are bad experiences but you can bootstrap your friends into a better group. That seems harder to change and it’s definitely a real need.


Services like Buffer.io or custom mobile/desktop clients that post on your behalf.

Basically only automation & power users.


>Facebook can scrutinize third-party apps

I can assure you that they don't. Anyone can have a third-party app that scavenges for private info.

See: Cambridge Analytica.

>there's no one who has access to holistically examine automated access and detect shady activity

There is. It is you. You can shut off access your data any time you want to. Yes, if you give someone access to some data, that data could potentially be out there forever but you can revoke access to your (future) data freely.


> Yes, if you give someone access to some data, that data could potentially be out there forever but you can revoke access to your (future) data freely.

And, most importantly, the same is true for literally any platform.

One quick look at people taking screen shots of snapchat posts shows how deletion of data from a platform like FB or Snapchat is irrelevant - viewers of that data can always copy it.


Facebook is going to scrutinize third-party apps now. They don't want another scandal similar to the Cambridge Analytica one.


I see that you don't understand the problems raised.

About accountability: if YOU are compromised, your friends' data are compromised, and vice versa. Are you saying that the median security skill of your friends are higher than Facebook? Because any of them can leak your data unintentionally.

About encryption: it's freaking useless in this case. Remember, some people fall for Nigeria prince scam. And what happen when their keys are compromised? See above.

That's the crux of the argument: you can't guarantee that your precious friends and family can safeguard their keys (in fact, I doubt my personal security practice is remotely as good as FB or Google or Amazon or MS or Apple). In that case, by the virtual of distribution, your data is copied everywhere, waiting for any key to compromise.


It boggles the mind that people still have the blissful trust in the security chops of giant corporations. I could give you a long list of well-funded corporations whose servers have been cracked in the last few years (remember Ashley Madison?!?), but I really only need to mention one; GitHub ...


The whole issue with facebook is that they:

1. Follow you from site to site, scooping up all the data they can on you.

2. Allowed all of that data to be accessible not just by you opening up to a bad actor app, but by any of your friends opening up to a bad actor app.

Calling it "overly open APIs" is misleading at best. The point of an API is that it is a public interface. If Scuttlebut has proper permissions controls then they wont have these problems... and because they're open source those problems can be scrutinized rather than remaining opaque.


Minor nitpick: API stands for "Application Programming Interface". There are plenty of private APIs in use right now all over the world.


Thanks for the correction! I did not know that. I guess that makes me one of today's 10,000.



How can Scuttlebutt prevent (2) from happening? If you share data with your friends, how can you know that they haven't installed an app that will slurp up that data wholesale?

The only solution would to be to enforce reasonable app usage in the client, and then require all your friends to use that client. That seems to defeat the purpose of a decentralised protocol.


Nothing can prevent that from happening. DRM cannot ever work. Facebook can't stop “friends” from slurping data either.

The SSB protocol has other design goals beyond “be Facebook but less evil”; for example it works seamlessly offline.


In my case, I don't care about the "privacy protection" of a given social network: I assume that everything I post is public (except private messages), so I filter what I upload based on that assumption.

Things I do care about:

-No censorship

-Chronological feed

-Open source & non-abusive client. (i.e. no tracking what users see or read)

-Good usability

I don't care about abusive content or fake news. If I see fake news, I just stop following whoever posted it.

So, under my criteria: decentralized > facebook


> -Chronological feed

Isn't this asking for a bit much? /s


> I don't care about abusive content or fake news. If I see fake news, I just stop following whoever posted it.

How do you know? Could you also tell me if my computer has virus, since you seem to have an oracle?


Maybe doing due diligence, reading a few primary sources, before you choose to believe or act on something?


if you can't tell the difference between real news and fake news, what makes you think `$whatever_arbiter` will do a better job?


Why did you ask me a question totally unrelated to my post? I am not sure that I do think $$whatever_organization can do better, but perhaps it has more resources to issue corrections.


It might also have its own agenda about what news it wants to be considered "real" or "fake".


You're missing one very large differentiator: user control.

With Scuttlebutt, largely, the client controls every one of your points. Different clients (with different settings/controls) can interact with a network upon which other users are using completely separate clients, each with separate settings controlling how user data is contributed to the network. Consent is not an issue.

With Facebook, as a user, you need to agree to Facebook's strict terms to be a part of their closed network, and—largely—cannot do so with your own client with its own data-contributing settings. The only close equivalent is using something like uBlock with your own browser, but the control you have their is very limited.

I say consent is not an issue but I'll devil's advocate myself and describe a Scuttlebutt setup where it would be. Say a company sets up a normal centralised service, which you visit in your browser, sign up for a central account, and it's backed by Scuttlebutt behind the scenes. Users of that centralised service can connect to a larger Scuttlebutt network upon which other users may be using their own dedicated clients to access. Consent is an issue for that central service (which acts as a defacto client on your behalf), but not for the network at large.


We fail to consider policy when thinking about centralized/federated services. Centralized services provide strong, regular policy adherence across the network, whereas federated services provide weak, irregular policy adherence across the network. Centralized services can effectively silence a bad actor. They may also silence a good actor, but generally only under external pressure from government. Federated services have little or not ability to silence bad actors across the network, though individual instances may effectively silence "bad" actors. However in this capacity "bad" is not well understood and can simply mean the instance administrator does not like the person the silence. Individual instances may also give voice to bad actors.


Why should “a service” silence anyone?

How about letting people make their own decision who they want to talk to, without a third party saying “I forbid it”.


Can I use an analogy from biology to shed light on the valid point you have?

Human beings exist as part of a society--a larger organism. Imagine if a cell were permitted to send any proteins or RNA it wanted to its neighboring cells. As long as the signals are benign or simply "nuisance" level, it's fine. But if the signals subvert the very organism of which they are a part--for example, by tricking neighboring cells into ignoring programmed cell death and encouraging enlarged blood vessel growth in the area--then there is a real danger that these cells are becoming a cancer to the host body that sustains their very existence.

I think the scare-quotes you put around "service" might be to show that a communication service that silences your communication is no service at all. But isn't that true of any complex, principle-based decision? If you have a friend who says he is going to blow up a federal building, and you report him, are you a "friend"? Some principles trump others--like saving lives over sustaining friendships, for instance. In the same manner, I think there are legitimate cases where a "service" should not serve.

How that should work in practice is still being worked out--in the halls of tech companies and legislatures all over the world.


How that should work in practice is still being worked out--in the halls of tech companies and legislatures all over the world.

You finally got to the crux of your argument after contorting around a bad analogy. Only tech companies and legislatures should be figuring out what services we should have.

Let me tell you something. That position is the complete opposite of what Hacker News is all about.


You know, I'm pretty sure when they said "legislatures" they were implying the imperfect-but-normal ongoing political process. The one which stretches across dozens of different countries and with some influence by the billions of non-legislator citizens.

Instead you seem to be a hurry to travel down a road that sometimes ends with the word "Statist" getting thrown around as an epithet against heretical outsiders.

> [Disparagingly:] Only tech companies and legislatures should be figuring out what services we should have.

Let's apply the same logic to non-digital goods and services: Do you believe it is fundamentally wrong for a government -- even with significant public support -- to interfere with one anonymous man's Galtian quest to sell radium toothpaste by mail?


Let's apply the same logic to non-digital goods and services: Do you believe it is fundamentally wrong for a government -- even with significant public support -- to interfere with one anonymous man's Galtian quest to sell radium toothpaste by mail?

Amazing...even after I point out his janky biology analogy, you go ahead and try one yourself. You people can't help but to double down.


Some people are interested in designing systems where no central authority can control anything, while others are more interested in determining which entity should have control over everything.


> You people

Yeah, that's what I suspected, we're done here.


> Do you believe it is fundamentally wrong for a government -- even with significant public support -- to interfere with one anonymous man's Galtian quest to sell radium toothpaste by mail?

Government? Maybe. Private corporations exploiting the hell out of a natural monopoly? Hell no. Genuinely democratic government (which implies opt-in, or at least the ability to opt-out) sure. That's what standards bodies are for.

Unlike some here, I can see value in user protection laws like the GDPR, for the same reason I see the value in governments creating heavy disincentives for kidnapping or murder. Such laws can, if necessary, be enforced on groups running instances of federated social network software. We saw what happened when the US Congress tried to regulate a major centralized provider; a slap on the wrist with a wet bus ticket: https://www.youtube.com/watch?v=CTv0MZBCQCs


Your analogy breaks down right away because people are not mere cells in the organism of a state. That is a dangerous mentality that can lead to Totalitarianism.

In your own example you alluded to cells refusing to commit apoptosis. By your analogy, it should be just and proper for people to be regularly savrificed for their state — their very lives may be required to be given up for the state to function.

I do not think we base our human societies on the law of the jungle — and certainly not on the inner workings of an organism! I doubt you are able to take this analogy very far without coming up against horrendous human rights violations.


By your reasoning, the DPRK should squelch dissidents because the health of the State as an organization trumps free speech between neighbors.

Any regime could apply this reasoning to prevent any threats to itself arising from people discussing things.


The GDPR argument is a bit moot because Scuttlebutt is no different than sharing pictures in gossip style (a.k.a. memes). If one of your childhood pictures happens to become the new meme, there's little hope that GDPR enforcement would suffice to de facto delete it from the internet: from Reddit, from Imgur, from independent websites, from Torrent, etc. The same is with Scuttlebutt, but data is primarily shared between friends without contracts, not from people to a particular company. GDPR applies to institutions.

The other points are just stating "much harder", which seems to just bring skepticism and little actionable suggestions.


I have similar concerns. If I had a magic wand, I'd solve this by splitting Facebook into an infrastructure-and-core-data non-profit and one or more for-profit companies that are building tools or interfaces on that platform.

I think there is a natural monopoly for some aspects of this, which is why Facebook is so hard to quit. But I don't think the whole thing need be in private, for-profit hands. Mozilla shows that a nonprofit can be a good steward of important web assets, with much stronger user advocacy than for-profit companies normally do.

Doing something like that for identity and interconnect between messaging and micropublishing providers seems much more robust than pure decentralization to me, which I expect would have the same failure mode as OpenSocial [1], where forces pushing toward natural monopoly are basically unchecked.

[1] https://en.wikipedia.org/wiki/OpenSocial


I think decentralisation is the wrong way to look at it. The protocol itself becomes the point of centralisation with many providers implementing in federation. Nothing to stop any of them being commercial (they may have all kinds of ease of use and features on top) or not. Since you lose the network effect of bigger player owning 'footfall' (e.g. ebay), there should be less natural tendency for monopoly and greater incentive towards user needs. For example, a more privacy conscious provider may choose to only share limited data with the wider federation. Others may be all about the exposure and getting more followers. (I'd expect federation to allow users a way to export their full profile+history and migrate to another provider taking their data away with them.)


If the protocol is what makes it work, then it's definitely not centralized. Look at email, for example. I love it, but it's past its prime, because it just doesn't evolve to meet new needs and new mental models.

Contrast this with how well proprietary messaging platforms have been taken up and improved iteratively. Or even look at how Google is advancing GMail. Email is nominally federated, but they have circa a billion users. 44% of US adults report using it, and it's 61% of 18-29 age users.


Standardisation would have been a better choice of words.

But this sounds like the old proprietary vs open source arguments. 1. The biggest tech companies in the world have struggled to keep up with the pace of innovation in open source. 2. Scale of userbase counts but standards facilitate this by creating a network and market. 3. There is a compelling business case for having an ownership stake in your tech platform which revolves around roadmap, security, and longevity. Longevity is counterintuitive but FB can bite the dust like Myspace, and Google can go the way of Woolworths. Huge institutional brands can evaporate fast and barely leave a trace; many young people today have never heard of Madonna, David Bowie, Led Zeppelin, unthinkable to older generations.

The way to differentiate on standards is via features and service, which gmail does well (spam was the killer feature which got most using it). But just lately Google has started looking at proprietary extensions to web and mail, and it's like Microsoft in the early web all over again. We saw how that turned out, even though it was unthinkable that MS wouldn't "win the web" at the time by their sheer scale, brand recognition, and a market share which amounted to a de facto monopoly.

(And funnily enough, Google seems to make the same product mistakes as MS, where it tries to boil the ocean in an orgy of featuritis. With a subset of the tech behind Wave they could have made a great competitor to Wechat/Line etc. Look at Slack - it costs around the same, possibly more than, Office 365 or Google Apps for Business, yet does a tiny fraction. Everybody knows Slack's only real differentiator is UX and service e.g. not having to run chat servers, bouncers, search etc. Again Google could have pieced a lot of Slack together from existing components in Wave. Feels like they are very shaky when it comes to executing product and it could be their undoing.)


For a properly designed distributed social network, there's no reason your data should be visible to anyone other than those you have approved.


What if people get tricked into approving malicious accounts?

Who is gonna police that?

How are you gonna prevent anarchy?


How are you gonna prevent anarchy?

Cats and dogs living together...oh my. Let me clue you in on something. In free societies there's risks and individuals make bad decisions, and we live with it. We don't need someone policing everything.


And this is the crux if the matter.

Ideally, there should only be a select few that determine which apps and programs should run for the masses. We should even control which software users have access to.. After all, giving the people too many choices leads to imminent danger on all fronts and is uncontrollable.

I'm increasingly convinced that there are a great many who relish the idea that the internet, privacy, software, and ultimately life should be state controlled, similar to China or North Korea, as long as It's their people making the rules..

It's 2018 and that would never happen though.


I used to think like this too, but once you dive deep into "decentralization", ironically you learn so many things that are infeasible and impossible with decentralization, and you start to appreciate all the shitty rules that you used to despise.

For starters, you say "free societies", but try to think deeper about what that exactly means. It's most likely a collection of nation states, each with its own governance and military and law. Everything around you works because of some sort of centralized authority.

Most people don't realize this--I myself who's a programmer probably would have died without knowing this if I didn't get into decentralized tech stuff--because they never needed to question why governments exist or why nations exist.

TLDR: Anarchy is likely to happen if there's no regulation. Even the Internet itself is regulated if you look into every party involved.


we certainly don't need to police everything...but there is a middle ground between that and no policing at all! And that will be hard to do in decentralized networks.


I agree there is a middle ground between policing everything and no guidelines or accountability at all. Every decentralized social networks that's pulled in a user base beyond the friends of the devs has had to deal with how to find consensus around guidelines, and how to deal with Bad Actors. Fortunately, in free code tech, everything we do revolves about rough consensus and running code.

So within a project like Mastodon, they define goals; eg a spam-free network). Then, they theorize mechanisms to implement those goals; eg give users the ability to mute/ block spammers, and give instances the ability to boot spammers, and mute/ block instances infested with spammers. Then they code those features, roll them out, and see if they achieve the goal. Rinse, repeat. Pretty much the same process a centralized open source site like Reddit, Lobste.rs, Minds, or Yours would use.

Things get a bit more complex when Mastodon wants to federate with instances of software other than Mastodon (eg GNU Social). Fortunately in tech, we have other names for consensus and guidelines about inter-operation between different programs implementing similar features; protocols and standards. For example, the W3C Social Web EG got a bunch of folks together from projects that want to federate, and standardized a set of protocols under the name ActivityPub. Because this standard is written by people with experience dealing with Bad Actors in federated networks of their own software, they can share this knowledge, and follow a similar set of steps to those laid out above.

In contrast, FB at al are the worst of both worlds. They have total power to police anything, and the only way to hold them accountable is to abandon your data and your contacts on their platform and opt-out (thus #deletefacebook). They accrue more power and wealth the more users they have spending time on the site (abusively or otherwise), so they do the absolute minimum to hold Bad Actor users accountable, just enough to other users getting driven off the site. See how centralization doesn't really help here?


People can get tricked into opening their door for robbers. This isn't a silver bullet - it would just avoid a central database with everyone's info that could easily be shared or scraped.


> What if people get tricked into approving malicious accounts?

Do you really need to idiot proof everything? I'd say just let natural selection happen at this point.


> Do you really need to idiot proof everything? I'd say just let natural selection happen at this point.

I'd say people with this mindset will be the first to be eliminated through natural selection, not because they're unintelligent, but because of the belief that they're intelligent and smart enough not to fall for this. The reason is: EVERYONE can fall for anything.


herd immunity is a thing that you're not taking into account. It's rarely about single indviduals, but the entire group.


Natural selection in this case means another Cambridge Analytica. Most people want to avoid that.


No one currently polices whether or not I accept a particular friend request on Facebook except me. There is no way for me to guarantee that the person I am accepting a request from is who they say they are and isn't going to scrape all my posts, personal info and photos.


It's a philosophical issue, negative liberty vs. positive liberty.

Positive liberty is the distribution of responsibility to the collective (and managing/controlling the collective through central bureaucracy), negative liberty is distributing the responsibility to the individual, self organization, or stateful components in dev lingo.

Your error is that you're set on only one perspective, positive liberty, like many people in europe. GDPR is like that, instead of giving people the tools to protect themselves, and not leak data in first place, and educate them about voting with their wallets, they just take it from the individual and apply it to the collective.

That's the mindset of centralization. It's clear that decentralization efforts fail if you insist on distributing the responsibility collectively.


Personally, I hope (and I think I'm not alone here) that on a network like scuttlebutt, there will be much less "noise" than on facebook. My timeline on facebook (whenever I check it, like weekly) is a mishmash of...

* ads (if using a browser that doesn't get rid of them)

* "you missed someone's birthday who you didn't even remember you were "friends" with

* look at this really popular post in your social vicinity, ENGAGE!!!

* cat/dog/food pictures

* politics of the same kind I had to ignore as a teenager, back then by mail. Sign $petition here!

* the occasional thing I give a flying fk about

This is not accidental. It is what facebook is built to do: keep you on their page, engaged. Scuttlebutt and such don't have that incentive. Liking "Pizza" or "Justing Bieber" doesn't exist. You can like a specific post, but that's not the same as putting your entire preferences on there. The possibility to digitally model your entire family and social graph and all your preferences in the open doesn't exist, simply because... why would someone implement that? And why would they then gear the UI to reward you for doing that? And it's not as inherently in danger of becoming an across-sites profile kept by a single entity.


> cat/dog/food pictures

I know you must be high school or college aged, because you didn't mention baby photos. Watch out. That's going to take over your feed in a couple years.


you guessed wrong. but those I could live with ;)


Mind sharing how you manage to not see tons of baby photos shared by your contacts?


But if users don’t stay engaged then how would they retain?

And if they don’t retain...how would it be useful to anyone when none of their friends are on it?


It's possible for people to be engaged because their friends are interesting; rather than because the service is designed to grab attention.


I would upvote this more than once if I could. This is the most important argument for "reason of engagement" as it should be.


But how the tool they use to do so is designed matters!

If there is too much friction then people simply won't adopt it


Yes, UX matters, especially when you are a new platform trying to establish your initial user base. But nothing matters in social software as much as network effect; people want to be where their friends are (and/or where people they want to follow or be noticed by are). Like any social network, Scuttlebutt will grow from the edges, as people already using it onboard their friends and family members.

(I had more to say about this but I posted the longer version on Diaspora instead.)


> 1. ... For distributed systems there are more ways to exploit the APIs and gather data on users.

However there is no global state, users only push-pull feeds of friends and friends of friends. (In part for privacy and in part for performance, you don't need to carry all the data for a social network to be useful)

> 3. GDPR compliance about deleting data is almost impossible in a distributed system.

However that doesn't apply to individuals that aren't providing a public service.

> 4. ... Open source software and distributed software tends to be much harder to use.

Yes, however there has been some exiting discussion around what UX could become possible in a decentralized context. See https://coolguy.website/writing/the-future-will-be-technical...

> 5. Any future concern/issue will be much harder to resolve if there are thousands of different instance running decentralized social networks.

There are no instances, only peers. (Pubs are sort of easy to connect to peers and there is work being done on peer discovery to outdate most pubs; they could still be used to connect communits around topics, hobbies, etc as a way to reduce the distance between peers)

> 6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data.

There is no retweeting/sharing, though there is work being done on Out of Order Messaging to propagate a single message along the follow graph and there is work being done on flagging/tagging feeds/ids and posts. (Along with some semantics around how to interpret the flags/tags to improve UX and user control)


> There are no instances, only peers. (Pubs are sort of easy to connect to peers and there is work being done on peer discovery to outdate most pubs; they could still be used to connect communits around topics, hobbies, etc as a way to reduce the distance between peers)

Why do you draw this distinction between "instances" and "peers"? A conventional understanding of the word "instance" would suggest it means "a running instance of the software system in question", which would suggest the word has no meaning distinct from what "peer" would mean in this context. Am I missing a critical and non-obvious distinction?

> There is no retweeting/sharing

My experience is that users really like these features.


> Why do you draw this distinction between "instances" and "peers"

I understand why you ask this, but the word "instance" has come to mean the server running something like MediaGoblin or Mastodon (the server in a server/client model), while a "peer" is an end-user device running a P2P app like BitTorrent or ScuttleButt (that is both client and server). P2P networks have their cons, but the major pro for a network not backed by large wads of capital is that they scale as they add users. Server-to-server federated networks using OStatus, Diaspora protocol, Zot, or ActivityPub have to scale by convincing people with scarce sysadmin skills to set up more servers, and figure out how to sustain them (both organizationally and financially).

> My experience is that users really like [retweeting/sharing] features.

Sure, but that doesn't mean every piece of network software needs to have them. They are one of the key tools for abusing The Stacks; post something you want to trend (spam, fake news), get a botnet of zombie users to boost it. Given the way Scuttlebutt transports and stores posts, they would create a lot of extra overhead, and potential for abuse, for no major benefit (people can always cut'n'paste if they really want to reshare).


> Pubs are sort of easy to connect to peers and there is work being done on peer discovery to outdate most pubs;

this is cool! could you explain more?

i thought Pubs were needed to connect with peers on internal networks, to alleviate NAT traversal issues.

what i would like to know more about regarding Pubs - but could not find any info on some time ago - is how much it will cost, more or less, to host your own Pub in terms of data transfer/storage, CPU, etc. and whether rate limits can be set to manage this.

nice to see your docs.. i have them bookmarked for later :)


Hi rapnie, I suggest you try the protocol guide, it has a section on pubs: https://ssbc.github.io/scuttlebutt-protocol-guide/#pubs


Well, it's not a Facebook replacement for the masses. It's more of the alternative in the way that Linux used to be an alternative to Windows long time ago. Linux was a nightmare for the majority, but for tech-inclined people (with a lot of spare time one might add) it offered a lot more safety and power, at the price that you had to learn how to set it up and use properly first. Same applies here. If you share data that shouldn't be shared it will not protect you, but if you know what you're doing it gives you a lot more control and safety.


Your concern about APIs in distributed systems seems to neglect the fact that cryptography can be used to ensure that only the right people have access to the data.

Although I do agree on the fake news point you make.

Edit: It seems that scuttlebutt does support optional end-to-end encryption: https://github.com/ssbc/secure-scuttlebutt#security-properti...


> cryptography can be used to ensure that only the right people have access to the data

That was my assumption too, but I have no technical knowledge on the subject.

If encryption was used, would that keep a rogue server admin from accessing sensitive user data?


You would encrypt the data before giving it to a rogue server using a key that reflects the access you want to permit.

So if you want your friends to be able to use it then you'll need a shared key with your friends.

But only the clients have the key, so the servers pushing the data around can't access it.

Edit: Check out how Keybase handles this.


> would that keep a rogue server admin from accessing sensitive user data?

There are no servers, it is peer to peer. The pubs are just easy to connect to to bootstrap new users into the social network and have been mostly closed off now that it has become more popular to avoid bad actors from abusing that easy way in.

You can bootstrap on a LAN / WAN without pubs.


It’s hilarious that people think Facebook could be held accountable. Senators didn’t say we need rules for privacy protection or that any specific response should be made by them to CA leaks, just a vague “do suff better or we might regulate you”

These guys really have free reign and just get a slap on the wrist WHEN ELECTIONS ARE MEDDLED WITH.

We should leave their platforms in droves to deprive them of power cause it seems like even the US Congress won’t stand up to them.


Alternative explanation: if they actually go after Facebook all the previous shady shit US politicians have done would also come into question. So they'll stick to emotive appeals like "when elections are meddled with" instead of specific, measurable outcomes.

Recall that the Obama campaign got the explicit go ahead from FB to violate their privacy policy, and built up equally large databases. Heck, recall Obama explicitly endorsing Macron. Does that count as large scale meddling?

What's hilarious is that the same people worried about internet driven misinformation are now the ones jumping into action because the media told them to #deletefacebook.


"1. The whole Cambridge Analytica issue was caused by APIs that are too open. For distributed systems there are more ways to exploit the APIs and gather data on users."

No, the issue was that other people had access to data they shouldn't have. there's no problem with the API being open if only the right person has access to the right data, ie, if access management is done right


You are mixing up openness of the code and protocol with access to data. Access to data should be managed by security features, and security through obscurity isn't the proper method anyway.


this entire complaint centers on the over-paternalistic notion that it is the service operators responsibility, rather than the users, to solve these problems, and that this is the desired state of affairs.

1) ... on the users that have chosen to enable this

2) ... for the users that use other peoples servers or servers from disreputable people, or share to those who do the same.

3) ... and? this presumes GDPR is a good thing

4) ... it's impossible to view a list of viewed messages, perform bulk operations, flag, sort, group etc. facebook to the same level that can be done in other 'archaic' technologies such as email. presuming commercial ui's are designed for user friendlyness rather than increasing user engagement, etc. is a red herring. also, strawman.

5) much like HTML, TCP/IP, SMTP, HTTP and everything else the internet runs on?

6) which is why spam filters don't work? and users don't have brains to do this themselves?


Preach!


The principle is that the network can become federated, which makes it possible to switch providers while remaining on the same network. This allows there to be competition between providers. Presumably, providers would compete based on their ability to protect your data. Facebook, on the other hand, competes almost solely based on the size of their network, which eclipses every other factor like accountability.


Scuttlebutt isn't a service. There are no “providers”, so I don't understand what “federated” means in this context.

It's a tool. The protocol sends data peer-to-peer.


You are assuming the network holds personalized data. While this is true for facebook (because this is their business model) it is not necessarily true for a non commercial social network.


Not saying that scuttlebutt is useless, but within the parent's perspective, almost everything applies as well on HTTP and HTTPS. But no one seems to care? I mean, google caches your website on their machines and so on, be it personal or not. I guess once things become ubiquitous enough, they start to become invisible. Whois service, I heard recently, was being scrutinized over personal data in the context of GDPR, so it's not ALL invisible.


> 6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data. So it becomes harder to address those concerns in a distributed setting.

Maybe people will have to start paying the market what this data is worth, as opposed to burying it in EULAs and using venture and angel funding to create a next generation data oligarchy more difficult to overcome than any financial oppression?


You're absolutely right. Distributed social networks are terrible, so we should stay on Facebook forever.

And if that is not what you are implying, perhaps you could explain what it is you do think we should be doing instead.


I think the idea is no ads -> nothing to target -> no need/value for personal data. Sure, maybe Cambridge Analytica can scrape Scuttlebutt or Mastodon but then what can they do with that data?


Create a army of fake users to influence people that way maybe?


Aside from the likely ability to connect it to other sources of data so they can show better ads on those platforms, there's regular market analysis - it's worth knowing that teenagers are increasingly interested in X even if you can't tie that back to individual teenagers.


It's an open source alternative to FB, which makes this a more efficient FB. You are very correct on all points.

Google and others operating a crawler would have the same data as FB has today.


Okay Hackernews, I get it. Scuttlebutt isn't fully ready for everything yet. I wrote that article hoping that it would sparkle interest to both use it, plus make it happen.

This is not your usual startup launch, it's a community project by multiple open source hackers. If something is missing, you can make it happen. And there are so many ongoing developments right now (see list below), that it really doesn't make sense, at this point, to point out the current problems with the protocol. It's evolving fast, and can evolve even faster if you choose to make it your own and do something about it.

Here are a couple of things being developed:

- Mobile app for Android

- Better cryptographically-verified user invites

- P2P replication over WebRTC

- P2P replication over DHT (Kademlia)

- Better scalability (Epidemic broadcast trees)

- GitHub alternative

- "Out-of-order" replication (get messages from distant friends of your friends)

- Private groups

- Moderation tools (every person as a moderator)

- Socio-technical discussion around data accountability

- New RPC stack, rewrite

- Rust client

- Go implementation

- C implementation

- Groundwork for iOS support

- Multi-devices accounts

- Scuttlebutt on Firefox as an extension

- Overall improving onboarding and docs

- Replication over Bluetooth and Wi-Fi P2P

- Web viewer

- Scuttlebutt cloud (easy way of setting up servers)

- Websites on scuttlebutt

- etc

It's a moving target


I'm super impressed with all you've done. I've been white-boarding similar ideas for a couple of years from the other side concerning protocol security, secure messaging, user identity management and related which utilizes Curve25519 and related crypto.

I think these ideas will change the world for the better.


Can you point me towards the Go implementation? I'd love to contribute.



(I'm the author of the repo in question)

Note that this repo has been sidelined, as I have fundamental issues with the protocol SSB is built on. Unless there's changes to how the messages are signed and verified, I'm not planning on putting any serious effort into SSB.


I'm curious to hear about the issues. SSB's network transport is supposed to be pretty okay: https://github.com/auditdrivencrypto/secret-handshake


example message:

    {
      "previous": "%26AC+gU0t74jRGVeDY01...MnutGGHM=.sha256",
      "author": "@hxGxqPrplLjRG2vtjQL87...0nNwE=.ed25519",
      "sequence": 216,
      "timestamp": 1442590513298,
      "hash": "sha256",
      "content": {
        "type": "vote",
        "vote": {
          "link": "%WbQ4dq0m/zu5jxll9zUb...KjZ80JvI=.sha256",
          "value": 1
        }
      }
    }
Signed example message:

    {
      "previous": "%26AC+gU0t74jRGVeDY01...MnutGGHM=.sha256",
      "author": "@hxGxqPrplLjRG2vtjQL87...0nNwE=.ed25519",
      "sequence": 216,
      "timestamp": 1442590513298,
      "hash": "sha256",
      "content": {
        "type": "vote",
        "vote": {
          "link": "%WbQ4dq0m/zu5jxll9zUb...KjZ80JvI=.sha256",
          "value": 1
        }
      }
      "signature": "Sjq1C3yiKdmi1TWvNqxI...gmAQ==.sig.ed25519"
    }
The signature covers the whole message, and is then added into the message it signed. The way this works means you have to encode json exactly the same way as the "main" node.js implementation. Emojis, unicode, html literals, EVERYTHING. Or else it will fail to verify. I've gotten most of it working, but there's still edge cases where I gave up trying to get them to work correctly.


I know that I sound like a broken record, but this is exactly the issue which canonical S-expressions were designed for, and which SPKI wrestled with & solved twenty years ago.

The SPKI version of a message would look something like (I've removed the hash property, because I don't think it makes sense for an object to specify the hash to be used to refer to it, but one could add it back in if one wished):

    (message
     (previous (hash sha256 |XphMUkWQtomKjXQvFGfsGYpt69sgEY7Y4Vou9cEuJho=|))
     (author (public-key (ed25519 |FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=|)))
     (sequence 216)
     (timestamp "2018-04-19T17:53:26Z")
     (content (type vote)
              (link (hash sha256 |DlBH/hCmXfVzks2uY+WIll4aTzxrfBA8m/3GIdX3Vew=|))
              (value 1)))
The transport version would be this (you can Base64-decode it to see the canonical version):

    {KDc6bWVzc2FnZSg4OnByZXZpb3VzKDQ6aGFzaDY6c2hhMjU2MzI6XphMUkWQtomKjXQvFGfsGYpt
    69sgEY7Y4Vou9cEuJhopKSg2OmF1dGhvcigxMDpwdWJsaWMta2V5KDc6ZWQyNTUxOTMyOhQl/7bA
    y6bmwjyinyK8OIHPkkJB3Gg9e7OxiOov84lmKSkpKDg6c2VxdWVuY2UzOjIxNikoOTp0aW1lc3Rh
    bXAyMDoyMDE4LTA0LTE5VDE3OjUzOjI2WikoNzpjb250ZW50KDQ6dHlwZTQ6dm90ZSkoNDpsaW5r
    KDQ6aGFzaDY6c2hhMjU2MzI6DlBH/hCmXfVzks2uY+WIll4aTzxrfBA8m/3GIdX3VewpKSg1OnZh
    bHVlMToxKSkp}
And a signed message might look something like:

    (sequence
     (message
      (previous (hash sha256 |XphMUkWQtomKjXQvFGfsGYpt69sgEY7Y4Vou9cEuJho=|))
      (author (public-key (ed25519 |FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=|)))
      (sequence 216)
      (timestamp "2018-04-19T17:53:26Z")
      (content (type vote)
               (link (hash sha256 |DlBH/hCmXfVzks2uY+WIll4aTzxrfBA8m/3GIdX3Vew=|))
               (value 1)))
     (signature (hash sha256 |XphMUkWQtomKjXQvFGfsGYpt69sgEY7Y4Vou9cEuJho=|)
                (hash sha256 |5hHMWc1PqfrwFVfALci5JXCWqW7VC4I4iS4+Utvr44w=|)
                |z7W1ERg9UYZjNfE72ZwEuJF79khG+eOHWFp6iF+KLuSrw8Lqa6IousK4cCn9T5qFa8E14GVek4cAMmMbjqDnAg==|))
Canonical S-expressions already buy you bit-for-bit identity when hashing, and SPKI (as an example) wraps signatures rather than injecting them — the only sane choice.

Why do I bring this up? Obviously it's possible to make JSON be a cryptographically-sound format (either by foregoing objects for arrays, or by rules around object-field ordering, along with other rules about encoding), but using it instead of an already-sound format indicates an unfamiliarity with prior work in the field.


One slight correction: I realised later on that in the current draft spec, unquoted tokens must not start with a digit. Thus the example would be:

    (message
     (previous (hash sha256 |XphMUkWQtomKjXQvFGfsGYpt69sgEY7Y4Vou9cEuJho=|))
     (author (public-key (ed25519 |FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=|)))
     (sequence "216")
     (timestamp "2018-04-19T17:53:26Z")
     (content (type vote)
              (link (hash sha256 |DlBH/hCmXfVzks2uY+WIll4aTzxrfBA8m/3GIdX3Vew=|))
              (value "1")))


Perhaps more to the point, the need for canonicalization in this use case is well understood from not only canonical S-expressions, but similar things done in XML and other cryptographically signed structured data formats. While not using one of the existing formats is not necessarily a bad thing, overlooking the well-established need for canonicalization is quite bad.


Agree completely. I don't know if I'd choose s-expr, but at the bare minimum, wrapping with signatures is the sane thing to do.


Yup, I've got an implementation of http over packet radio I've been working through and came to the same conclusion. Header contains the signature, base64 the message for verification.

Even though it's super low bitrate(1200bps/9600bps) since you have a binary foundation w/ base64 you can send raw binary to get low over-head but then easily verify+decode since base64 is well supported across a wide range of languages.


Which large scale open-source or commercial software is using s-expr today?



Hacker News. Emacs. Anything Lispy.


Why do you ask?


Wow, that hurts. What solutions have you suggested to the project?


I had expressed interest in changing it, but it would require changing the core data structure the network is built on, and basically be a breaking change that would almost inevitably result in having to start the entire social web over from scratch. Didn't see huge interest from the devs in doing so.


It sounds like the best path forward might be to document the NodeJS serialization format in perfect detail and create a test suite to verify all known corner cases. Until that's done, alternative implementations will be unreliable.


What are the potential downsides of not changing it?


Makes it difficult to implement the protocol in anything but node.js (and potentially version specific, if node.js ever decides to tweak json serialization stuff)


Objects in JSON are per the spec unordered, while the signature scheme here most likely relies on the order of the object's key-value pairs.

Other data formats that are ordered, and serialize somewhat more deterministically, are CBOR, Protobufs, or s-exp.


This is the same reason I lost interest. I may have stuck with it if the Rust crates weren't AGPL/GPL. (And thus can't be used in Apple's app-store which is an interesting target to me).


Would you be able to elaborate on these issues?


did so in sibling comment


It certainly seems interesting. I tried to test it out quickly today, but couldn't connect to any of the public hubs.


Nice work...impressive work. Are there any plans to add this to the freedombox? I think it would make a great fit!


2018 will be the year of "alternative to facebook" apps that are in no way an alternative to facebook.

To be an alternative to facebook, it should at least do 50% of what facebook does, and it should be accessible to all.

Anything that takes more than 3 steps to get it running it's going to keep people out. And if you keep people out, you don't have a social network, at least not anything like facebook where your grandma and people you went to school with but never met (or pretend you never met) are.

Plus you need marketing, a business plan, and so much more than just code that puts people together on the same page.

I hope for a social network where the data belongs to the user, but unless you get the complication out of it... it will be just something cool but not worth the time.


>it should at least do 50% of what facebook does

It's a common mistake to attribute the success of Facebook to its features (it boils down to microblogging + threaded discussions). The usefulness (i.e. product from a marketing perspective) of Facebook isn't its features, it's the people who joined it. Look at Google+, it's not that bad in terms of features. But it lacks people, therefore it's not a competing product. A competitor would be not someone who does 50% of what FB does. It would be someone who has 50% of what Facebook has.


Ahh, see, this is the second problem with Facebook alternatives- everyone misunderstands what other people use it for. For a younger demographic Facebook is not about microblogging at all. It's a (a) chat, (b) photo sharing, and (c) event/group organizer website. Everyone I know has a Facebook and uses it daily- can't remember the last time any of my closest friends posted a status.


> it boils down to microblogging + threaded discussions

I use facebook only for events, groups and chat.


Completely agree.

I am very interested in the UI/UX opportunities for training the decentralized generation how to interface with decentralized systems and manage their identities, especially across devices and contexts. This has been my biggest criticism of pretty much all of the attempts at a decentralized version of an existing mainstream web service that I have seen.

I love the decentralization community but it often feels very much like an engineer's realm, probably because it's mostly interesting from an engineering perspective. Maybe it's just who I follow, but I don't see a lot of activity in this area from user experience designers. Some collaboration could really help build a decentralized service that stands a chance of truly competing in the global space. Thus far I think it's highly unlikely the average mainstream user will convert.


very much agree.. i have been making that point (more or less) to the Dat Project community. no interest.


You can build 'a facebook' in Drupal which is more or less functionally equivalent and people have been doing that for years. But you still have the real work - building the network of users, which is where the value lies and not the software features (which are mundane in the case of fb).

What's far more compelling but challenging is open source federated social networking, which is a facebook on rocket fuel and overcomes the network effect as each provider implementing adds to a shared network. Even if it takes decades, this is going to be the inevitable model and fb will end up either joining in as a provider or do a myspace.


> What's far more compelling but challenging is open source federated social networking

OK, but that's not this. Scuttlebutt is peer-to-peer, not federated. There are no servers.


"You need ... a business plan."

I don't agree. What is the business plan of email (by which I mean SMTP, not some webmail provider)?


You're absolutely right! A protocol doesn't need a business plan.

Of course, a protocol by itself isn't very useful. You need services using it and systems implementing and supporting it, which do cost money and require some kind of resourcing model...


You don't need services when you can just use tools.

Is Morse code less useful because of the lack of viable Morse code service providers?


You're once again absolutely right! You can use tools without service providers.

You can use Morse code without any service providers whatsoever! Though using it to send messages solely to yourself might not be the best of all possible uses, it's absolutely a viable use.

Similarly, you could implement SMTP for yourself on paper. It might not be quite what was intended or maximally useful, but it's certainly a use. Some people might opine that it's far more useful with services implementing it widely and making its benefits available to many. I can't say they're being wildly unreasonable.


> by which I mean SMTP, not some webmail provider

Cheap cop-out. "some webmail provider" is what runs 99.999% of email. The people who run their own email, or run off hobby email servers, are insignificant.

You can't turn a blind eye to where the majority of users are going to be if you're implementing anything that actually needs traction in order to be successful.


No, there will always be a provider to webmail because there's demand for it. "Some webmail provider" is irrelevant, nobody is tlaking about people who run their own server here.

Federated social networks are like email: each instance is like the "webmail provider" you can pick and chose and some of them even come with their own clients and bells and whisltes.

Protocol doesn't need a business plan.


Each instance needs a business plan (or a way for the user to benefit directly). Those that don't have one either disappear or never grow past a few dozen users which is not enough on its own to push the protocol's adoption.

How is this so hard to understand?


You're confusing a protocol with a product (or in Facebook's case, hundreds of products).


billions of products is more accurate.

Products in developed countries is much more valuable than products in third world countries.


True! A protocol doesn't need a business plan!


One can always hope. But, we all know where "this is the year of..." gets us in the software industry.


Some day The Year of The Linux Desktop is gonna prove all the skeptics and doubters wrong.


The Year of The Linux Desktop is certainly coming sooner than the Year of the Windows Mobile ;P


Don't worry, I'm a dreamer too.


I really love the concept of this. I travel a ton and am without internet for days/ weeks at a time. Scuttlebutt allows me to keep up to date with friends and communities while offline and when I do eventually get online, just grab the newest updates and download them locally.

This is such a cool thing in my eyes for parts of the world with little / no internet access. The creator of the project (AFAIK) sails around the world and, again, has little internet access. this allows him to keep people updated when he eventually does find internet.


Your explanation of the offline utility definitely makes this more interesting.


What is this "offline" you speak of?


When I'm on a plane and Gogo is moving about dialup speeds, while blocking protocols that would make dialup usable.


It isn't an alternative to Facebook unless my grandma can use it, and she couldn't set this up for herself.

The idea that centralized storage is the problem masks the actual concern. There is nothing inherently wrong with centrally stored data. There is a problem is when it is locked down by a 3rd party, and/or you don't control how it is used.


> There is nothing inherently wrong with centrally stored data.

I'd argue that a 3rd party having the personal details and communication logs of 2 billion people is a massive problem. Privacy, governmental data requests, accidental information leakages, profiling, job applicant scrutiny, fake news, spam, data misuse by employees etc. Or even worse, in times of war.


What does this have to do with centrally stored data. Having data in a central store doesn't imply third parties.

If the store is decentralized, then any party could be equivalent to a third party, and therefore anyone has access to your data.


> Having data in a central store doesn't imply third parties.

How is that going to work then? Every single company holding your data in a central place is mining it today and selling the information to advertisers.

On a distributed network you replicate data only with people you choose. Since you're not going to add a government (or an ad company) to your friend list, they won't have your data. Private communications are encrypted and flowing directly to the recipient, so there's no port that agencies can tap into to listen. There won't be any big data to analyze, since data is spread across the network. Backup is easy, it's just a folder. Fake news never gets promoted, since there are no paid promotions.

Spam is a non-issue since there are no advertisers. There's no way to get into your feed than through your friends. There's no server or central storage, so employee misuse is not an issue. And you can have as many identities as you choose, there won't be a mandatory real name policy.

I could go on.


"Every single company holding your data in a central place is mining it today and selling the information to advertisers."

That doesn't mean it has to be that way in the future though. There are centralized social networks that are charging money for their use, and they are not selling to advertisers nor are there any.


but how is that guaranteed? If there's a single source of data, its a bigger target for bad actors, and a single source still needs an owner of some sort that you have to trust isn't going to cheat or change the rules in the future.

With decentralized, you still have the same issues (I don't really know how you solve those unless data transfer is truly peer-to-peer which I think causes discoverability and similar issues to usability), but at least the scope of them is inherently limited and you can opt in/out of the source based on your trust of it.


Replace advertisers with governments, and your centralized store has now been breached. See Lavabit.


> How is that going to work then? Every single company holding your data in a central place is mining it today and selling the information to advertisers.

It doesn't matter how it works, the fact of the matter is that while logistically third parties are typical in today's environment, they aren't implied by centralization.

Does Amazon's s3 sell your data to third parties? No. It's still centralized though!

> Since you're not going to add a government (or an ad company) to your friend list, they won't have your data.

Except when people use things like hashbase.io because they can't afford to run the server program 24/7 themselves. Then the hashbase.io analogous service sells your data to a third party, and congratulations you've got a system that has all of the lose of distributed systems, with all of the lose of centralized systems.


This is precisely the point: only give data to people you trust.

If Alice wants to communicate with Bob, she shouldn't be obliged to trust Facebook too.


Actually with a few tweaks, this technology would be much simpler to use than Facebook, for a person like your grandma, simply because it removes that annoying registration process. You just open the installed app, and that's it.

It's odd that we got used to the idea that "(1) registration, (2) strong password creation, (3) username selection (in case of conflicts), (4) email verification link, (5) login" is somehow a good user experience.


I have a question, how would my Grandma signal her identity to SSB from multiple devices? Say she has an iPhone and an iPad and she wants to use the iPad at home and the iPhone when she's out. I imagine it's not as simple as installing the app on both devices in this case? I'm curious how this is approached.

Cycle.js and xstream are amazing, as an aside. Thank you.


Using the same identity from several devices is not yet implemented.

Eventually, the client will probably have a “that's also me” button, which you'll press on both devices to confirm.


>It isn't an alternative to Facebook unless my grandma can use it, and she couldn't set this up for herself.

Facebook isn't an alternative to email if my grandma can't use it.

Computers aren't an alternative to telephones if my grandma can't use it.

Telephones aren't an alternative to mail if my grandma can't use it.

etc.

---

It'll get easier and simpler, I promise.


This is a variant of survivership bias and says effectively nothing.

Just because things have gotten more complicated and people have used them doesn't mean that people will start to use any complicated thing.

For example:

Google+ / Google Wave isn't an alternative to email if my grandma can't use it.

GPG isn't an alternative to talking in-person communication if my grandma can't use it.

... etc

Yes, you have valid examples where things that are relatively complex did become popular, but there are many many more examples of things that were more complicated and failed.

Just because scuttlebutt is complicated is not a reason it will succeed, but is indeed a valid reason it might fail.


My Grandma definitely skipped from a corded phone to an iPad with Facebook and right over email. It's still too complicated for her.


And yet billions of people use email. Goes to show the grandma argument is not very useful.


Most of them using an interface like gmail, which unsurprisingly looks a lot like (facebook) messaging.


Sure, thinking about user experience and designing user-friendly UI is important. But multi-million dollar UI and the ability to scale without losing performance (due to deep pockets) are the only reasons to use FB, goOgle or any of The Stacks. Once more UX people and graphic designers start working on decentralized, free code apps, and organic growth via community-hosting (userOps) allows them to scale as well as corporate server farms, where does that leave The Stacks?


Okay, but FB wasn't something your grandma used when it began.

Arguably it isn't FB if regular college kids can't use it. If they can subsequently onboard less tech savvy people, so be it, but that could be a future goal.


Why do we even want to be in a creepy digital relationship with our grandma? I used to think like you, then one day I realized that the real life is outside, I began calling my aunties, visiting them, and also created a Whatsapp group so the big family can have fun & share updates.


You do realize Whatsapp is owned by FB, right? so it's a "creepy digital relationship with our grandma" in exactly the same way messaging Grandma on FB is. The key issue here is not whether we use digital comms channels (or telephones, or carrier pidgeons), but whether those comms channels lead us towards getting together in person with our families and friends, or whether they lead us towards spending more ticking clicking around the comms channels. Check out Joe Edelman's videos on Vimeo about human-centred design for a more detailed discussion of this and related issues.


I live at the base of a mountain, and hike every day after work. I spent all last summer exploring every park in my state, and was on the news as an expert guide for some of the outdoor activities in my area. So you are presuming a lot by your response. My grandma, on the other hand, is in her 90s and not very mobile, and can keep up with family via their digital presences. Like you said... "the big family can have fun & share updates".


> It isn't an alternative to Facebook unless my grandma can use it, and she couldn't set this up for herself.

I wonder if Facebook is perhaps just not worth it.


I downloaded Patchwork after someone talked about Scuttlebutt on HN, but when I tried to join any pub servers on their Github repo, none of them worked/connected. 30 minutes later, I uninstalled the thing.

The idea was interesting, the UI was pleasant, and I could see this working at some tech conference where people connect with each-other and there's a common pub server so people can keep in touch afterward, but I don't see uncle Joe or grandma using this thing over FB.


I joined a pub but 90% of the messages in my feed were other people joining the pub and subscribing to topics. 9% were people introducing themselves as new to Scuttlebutt. 0.9% were either talking about Scuttlebutt or unreachable, and 0.1% were actual content.


Sounds like you joined during a wave of new people and were only getting posts from your shared pubs. Did you contribute any content yourself and build out a network and thus increase your feed? I've been on for a year now and there is a ridiculous amount of information to read.


I was held back from using Scuttlebutt because of how convoluted it seems. I browsed the website for 30 minutes and I couldn't find a concise, written explanation of how the protocol works. And now this? If I subscribe to a pub I see all crap everyone is posting? What's the point? I'm better using twitter

I really like the idea of a distributed social network, but it needs a simpler, straightforward protocol. And it needs to be free of clutter.


Yeah, I had the exact same experience. It's cool conceptually but basically unusable at this point.


That's just now. It's evolving fast, and two new developments will improve the onboarding problem: WebRTC-based invites, and connecting p2p to friends through a DHT (Kademlia).


Same. Just tried to give it another shot and there's only 3 public servers and none are currently working


Public servers were a temporary hack and nowadays most of the community is putting their public servers down. It's not a good idea for scaling, but above all, public servers connect you with strangers, which is basically undesired for a social network with a similar use case as Facebook.

There should be a pub server for each real community. I know it's not the most user friendly, but it suffices that one person in a real community of friends is techy enough to set it up, and it's not that hard: http://butt.nz/install?url=https://github.com/ahdinosaur/ssb... (this tool enables you to install your own server with a few clicks)


You have to handle the case of people who belong to multiple communities though, whether through context switching or otherwise.


Intersections are allowed. It's not like you need strictly one server per community, because servers are just mirrors of each community member. In fact, when a server goes down, no data is lost and it's easy to put a new one up.


hey, have you tried contacting a private pub? i'm Mikey, owner of `one.butt.nz`, happy to give you an invite if you send me an email! mikey@rootsystems.nz

if you want to setup your own pub, i made an automated Digital Ocean installer (also a detailed manual) for a Docker-based pub: http://github.com/ahdinosaur/ssb-pub.

i'm also working (with funding from #ssbc-grants) on a hosted pub-as-a-service product: http://buttcloud.org.


i am interested to know about usage characteristics for running a Pub (bandwidth, storage, CPU) to be able to gauge what it will cost me to host one myself.

curious to know about your experience with that.

also is there a way to set rate limits?


It's not an alternative to Facebook (or even Google+) for two reasons on viability for users. Firstly, it seems to have one client in development for Android, and none for iOS. Secondly, it doesn't offer a way to use multiple devices (with activity synced). [1] This restricts the platform a lot. I've been looking at Scuttlebutt once in a while for sometime, but I don't think it's developing fast enough to be a contender.

I'd really like to have a decentralized offering, but unless it provides the key features Facebook does, like the timeline, newsfeed, groups and pages, it'll be a very hard sell to get others on board.

[1]: https://www.scuttlebutt.nz/faq/applications/multiple-devices...


Okay, but the immutable references sure make it hard to get rid of stuff once you've put it up there...

I much prefer the DAT protocol, which has mutability built into its assumptions about how people will use it.

I know you could do the same thing with an immutable protocol, but Scuttlebutt is a perfect example of why immutability shouldn't be the default. Try deleting something you put on there and maybe you'll see why. I couldn't figure out any obvious way to do this. I'd imagine that's because nobody has coded the "mutability feature" for deleting posts.

Mutability needs to be built in. You shouldn't have to reinvent the wheel (mutability) every time you need it.

Beaker Browser/DAT is a much more interesting decentralized experience in my opinion.


I wanted to take a look at how it works but the on-boarding process is not really welcoming. Getting started [0] redirects to this weird site [1] served over plain HTTP, installer is also not signed :(

[0]: https://www.scuttlebutt.nz/getting-started.html

[1]: http://dinosaur.is/patchwork-downloader/


Have we reached the point where plain http seeks not welcoming. If the site above doesn't require you to login why do you think you need https? Is the only reason to hide your visit to that site from your isp?


Umm, the site in question is a big button to download something to run on your computer. You don’t think it would be bad if someone hijacked that and had people downloading malicious software?

You seem to misunderstand https... for one, it doesn’t hide your visit to that site from your ISP; they know the IP address you visited, and due to SNI, they will even know the domain. The point is to make sure you are connecting to the site you think you are connecting to.


The idea of https to have a secure communication channel where you can verify that the other party is who they say they are. Each https domain needs a certificate that is bound to the domain. It is a good way to prevent malware to be installed on your machine.

A website only needs to require you to login if they want to make sure that you are who you are and/or to prevent others from accessing information that you have shared with that website.


HTTPS can be used to verify that the host is actually the host we think they are. This is especially useful when we're downloading executables/scripts.

A plain HTTP site which is merely informative is perfectly reasonable.


short answer is - yes, we've reached that point. https by default is a reasonable default, in part because cpu and latency costs of https are basically zero for most implementations. And the implementations where it's not zero can afford the cost.

Given the almost-no-cost of the choice, why default to the less-secure alternative?


Anyone else not even use social networks anymore? Privacy or not, it's just garbage. Facebook, myspace, hello, whatever it's all the same crap with different CSS values.

Do we even need social networks anymore?


>Do we even need social networks anymore?

Shockingly, it turns out the world includes people whose habits and preferences differ from yours.


Ironic words from a HN user with over 10k karma.


This isn't a social network. Do you see me posting picture of my bathroom/kids/furniture/food?


Forums are typically considered social networks, although I suppose the definition is debatable. Whether users discuss their daily lives is not the standard, though. On Twitter everyone just kvetches about the news, and it's still a social network.


I haven't started hearing the term "social network" until myspace showed up. While forums may be that by some technical definition, in practice, there seems to be a core difference.

For one, forum communities tend to be focused on a relatively small group of people in that forum.

Twitter, Facebook, etc., tend to be fully global with the idea that anyone can access anyone else. Presence of media, I think, also matters a lot. On many forums media exists, but is not visible to unregistered users. There's an aspect of "you join or you're an outsider, and if we don't like you we can make you stop joining".

I don't know if I can straight up define it but there seems to be some fundamental difference between Facebook and your random hardware forum.


I thought that sort of thing was rare on Twitter now. Twitter seems to usually be about topical things, news, and that ilk, no? It’s a social network.


I don't use social networks, unless you consider Reddit, HN and Youtube social networks.


You might have point...But can we keep HN?


Obviously, this is where the cool kids hang out.

We don't need those lame squares and their dank memes.


I thought this was being done by Diaspora? https://diasporafoundation.org/

What's new/different here over this and other efforts?


Diaspora is federated, which for non-technical users is worse than FaceBook itself. The individual nodes (to which thousands of users are connected) will have far fewer resources to secure themselves than a behemoth like FaceBook. Also, uptime, badwidth etc.

ScuttleButt is peer to peer, somewhat like torrents but for data feeds.


Minor note to readers, it's partially p2p. It uses gossip, so at times your peer might be a semi-centralized server, and at other times it could be a peer.

I know that doesn't make it not p2p, but reading p2p makes me think I need direct connections with peers. Gossip is sort of nifty that way.. though I'm not a fan of semi-centralized redirect servers.


Considering it didn't seem particularly difficult to operate your own relay server, I don't really consider that much of a negative.

Spin up your own relay, generate some invites for your friends, and share all of your gossip through a server that you control yourself.


> Diaspora is federated, which for non-technical users is worse than FaceBook itself. The individual nodes (to which thousands of users are connected) will have far fewer resources to secure themselves than a behemoth like FaceBook

That's a weird argument - it doesn't even make sense no matter how you look at it.

1. Security is more or less centralized as per core code and core protocol. 2. Why do you imply big monolith is secure than a small instance? Where's the logical connection in that?


It's more than the app (whose code and core protocol you've mentioned) - it's keeping OS up to do, firewalls, opsec, watching for suspicious activities: These are all things that facebook (the company) does that need to be taken care of on every pod/node.

If it's federated, it means thousands of accounts are likely going to live on each server - and many of those servers will be easy to hack. It is in that sense the facebook does a better job securing it (and they have shown that they can do opsec) -- not any theoretical "centralized vs distributed" argument.


a nice thing you have with Diaspora is it is adopting ActivityPub, an open standard by W3C, and thus being able to interconnect with e.g. PeerWeb and friendi.ca and other future impls.

curious what thoughts on this are.. could it be incorporated wit SSB (or Dat Project for that matter), or fundamentally different (ActivityPub is also federated, but doesn't have to be.. though i'm no expert on this).


Doesn't sounds like the Diaspora team have any plans to implement AP, which is a shame. Here's a fairly scathing write-up on ActivityPub from a prominent Diaspora dev: https://schub.io/blog/2018/02/01/activitypub-one-protocol-to...

Friendi.ca and Hubzilla can already interoperate with Diaspora using the Diaspora protocol. Here's a good guide to the current landscape of free code, federated social networks here, and which protocols each app supports: https://medium.com/we-distribute/a-quick-guide-to-the-free-n...


I like scuttlebutt but it is not in a form sutible for public consumption yet:

- Providing a "secure" system in nodejs (it does not matter how good your crypto code is I I can poison left-pad)

- Bad privacy behaviour: you can follow anybody, limited ability to have private/friend-only messages.


Not to be too meta, but the magazine this was published in is all about decentralization — I'm biased because I was involved in it, but if you're on this thread, you may want to check it out. Just launched: https://inthemesh.com


I've added it to my TTRSS instance, their initial articles look interesting. Will yet be seen if the content holds up on a regular publishing basis.


Nice, no RSS feed?


When in doubt, add /feed and it probably works: https://inthemesh.com/feed/


:) I knew it, but now I won't forget it!

Added, thanks and thanks!


Why are we finding alternatives to Facebook, when in fact we should really be educating ourselves and people to stop sharing every single bit of personal information about themselves online, be it on Facebook or a decentralized application.

The problem with Facebook is that it holds way too much personal information about a person - phone numbers, emails, a person's likes/dislikes, hometown, current location, etc, and because society has been 'programmed' to share so much about themselves, no thanks to social networks like Facebook that promotes building your 'profile'.

In fact, strip away all that personal information and have people share their thoughts and their dinner photos and what you get is just Twitter, Instagram, Snapchat or a blogging platform.

A decentralized alternative to Facebook will not solve the problems Facebook has because in the end even if you own the private key to your own data it's up to you if you want to share your data with someone or an app, and once you've done that to a malicious party, your social network is compromised. And as some have pointed out in this thread, a decentralized and open source alternative would be worse.

In the end, it's up to the individual to be smart about what to share and what not to share, and reveal as little about themselves as possible rather than parade it all out to the world or to their 'friends' list. All it takes is for someone not too technical to download a hacked 'client update' to their decentralized Facebook alternative to have everything they thought to be secure be leaked out.

An alternative that promises to be more secure than what it's replacing is just asking for more complacency. I'm sure we thought Facebook was extremely secure at some point, so why not share everything?


A large point of concern I do not see discussed with centralized currator like FB is the ability of massive cesnsorship


I still think that's an awful name.


It's a protocol, not a product. Just make a new product that uses the protocol and there you go, a new name.


100% agree - names matter.


I don't think you say you contact over some HTTP or HTTPS protocol, you just say that you contact over twitter or fb or some other product that is built on top of this :3 In the same way scuttlebutt is just the name of the protocol not the product.


Users manipulate applications named Patchwork or Patchbay, for instance. Scuttlebutt is the protocol.


Ya, I would be afraid to ask an acquaintance if they are on scuttlebutt. It sounds like some kind of illicit pirate drug in that context. I wonder if Facebutt would be trademark infringement...


Faecebook


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: