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.
> 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.
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.
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.
> 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.
> 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.
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.
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 ...
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.)
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.
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..
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.
> 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.
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.
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.
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.
> 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 :)
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.
> 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.
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?
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.
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?
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?
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.
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)
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.
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.
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):
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.
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.
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.
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.
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)
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).
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'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.
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.
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.
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'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.
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.
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.
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.
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.
> 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.
"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.
> 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.
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.
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.
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".
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.
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).
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)
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.
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.
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 :(
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.
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.
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.
> 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).
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...
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
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?
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.
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...
The fact that one cannot delete or modify the history of a feed one "owns" is a show-stopper. Of course, people can always mirror stuff, but that is no argument against modifications.
If one stops to think about it, not being able to ever delete by design is a ludicrous concept when it comes to social networking. It takes relatively isolated cases of people mirroring and publicising stuff without consent to an extreme.
Never expecting to need to delete is akin to expecting that you've peaked in life already and future-you will not be looking back and cringing.
Facebook's "On this Day" feature I believe has helped a lot of people realise this - at least when it comes to users who have been around for ~10 or so years.
It might well be possible that the solution to Facebook and Twitter isn't more internet social networking, but more real life networking. So while some people appear to be raving about the merits of Steemit and Mastodon, many more are probably already too jaded to continue on yet another "social" network. The problem isn't necessarily the technology if the problem is us. Fixing societal and political problems by trying to throw more technology at it isn't the answer.
Are there others like me who tend to read "alternative" as a misnomer in stories about "decentralized X as alternative to centralized Y?"
I take git vs. svn as what I think is a fair reference point. Someone can still argue in favor of svn, but I don't think they could seriously argue that git isn't a viable alternative.
Moreover, git is so popular because it specifically targeted svn's users. Scuttlebutt does not yet meet that standard-- at best its a framework on top of which a yet-to-be-built Facebook alternative might sit.
I don't want to be a pest but the barrage of FLOSS "alternatives" to Facebook/Twitter can have a numbing or frustrating affect on readers who don't reflect on this discrepancy.
But I don't see any of these services taking over Facebook or even making a slight dent. What might happen is that Facebook dies a slow death and none of my friends keep in contact on there. But then none of us really built up and real friendships on there so there's no incentive to start again on another site.
I guess, even say we all got our wish and Facebook died, I don't see utopia running up behind it. Utopia for most geeks was probably the early days of the internet. I don't see anything bringing those back.
I don't think it's so entirely depressing if you can recognise Facebook for what it is and be free enough of it while your "competition" stays there and stagnates.
Focus on what you want from life and ignore the rest.
Scuttlebutt is a great idea and has some really smart people working on it ( like Andre and Dominic ) .
With that being said, I don't think Scuttlebutt has any chance of succeeding. SB network has some fairly serious architectural issues which may or may not have solutions that are achievable with the current design. I ended up uninstalling.
toxic users is a definite thing, but I think scuttlebutt is the best alternative social network I've ever found. the development community & the rest of the community are largely awesome, and they actually have a ton of funding.
Did they though? All I've been able to find related to this is a markdown document not updated in two months.
The company mentioned to give the money, "Dfinity", has no mention of Scuttlebutt on their Twitter, Medium, or company website. I can only seem to find things related to the Dfinity token presale and airdrop, which I assume is an ICO.
Scuttlebutt would greatly benefit from having a real source of funding. If anyone can provide proof Scuttlebutt is now funded please post it here.
The biggest problem with SSB right now as a FB alternative is there's no way to sign your messages so only your friends can read them, unless you have only 7 friends.
The utility of Facebook is that I can share things privately with friends and family. There are already lots of alternatives for public sharing.
If I may, a decentralized alternative to facebook would be community-based, allow people to do group chats, discover and post events, see attendees, meet each other, add each other to contacts, maybe even drive each other to the events, date, book group reservations at local businesses etc.
Yes that’s my project. Would love to get feedback.
(The things I mentioned above are actually social things, the main thing that distinguishes them is that they are taking place in the future and group collaboration online is always leading to a goal. Anything that doesn’t satisfy those two criteria is more about socializing online than offline.)
FWIW, I did a survey of people asking which features from Facebook that absolutely must have to consider switching to a replacement. As much as people say the events, chats, and local community features are important... exactly zero people checked those boxes in my survey results. Pretty much the only thing people checked was 'connect with friends'
You've missed the point and likely didn't do validation before building this (if you have).
I don't want 1,000 features from launch. Facebook didn't start out doing everything they do today, neither should you. Copying another service won't win you users because maybe users don't like that feature or how it works.
I want something that solves a problem without unnecessary doohickeys glued on to it.
So basically throw out everything you've suggested and start over. What does a social network mean in 2018? What pain point can you solve easily without a lot of work?
Don't spend more time on this than you need to, to get it in front of users who will tell you whether they will like it or not.
Facebook may not have started doing everything they're doing now, but they do have it now. Any new competitor is not going to be judged based on what Facebook was 10 years ago; they're going to be judged against it now.
I think the point is facebook didn't have everything myspace did when they started but brought in users for what it offered. What they offered was a semi-private network for your college. Very local. Only later did they open up to all.
Could the Iranians have a malicious node join the scuttlebutt network to crawl and identify nodes hosting content for dissidents? Aren't scuttlebutt nodes more susceptible to DDOS than Facebook or Twitter? Are there features in scuttlebutt to mitigate this?
* AP is a decentralized protocol, like email or XMPP, that standardizes federated interactions from server-to-server, and interactions from server-to-client. Sharing data between end users depends on one or more servers.
* SSB is distributed protocol, more like Git or BitTorrent. It has a concept of "pubs" which play a supernode role vaguely similar to that of BitTorrent trackers, or maybe a WebRTC server. Sharing data between users is P2P, not mediated by a server, although the pubs help user locate each other.
I started looking at trying to write an implementation of the protocol documented here: https://ssbc.github.io/scuttlebutt-protocol-guide/. I was surprised just how little information exists on the handshake and message exchange protocols. The reference implementations of both seem quite immature.
Was there no existing protocol for sending P2P messages between clients this could have been built on top of?
> What makes Scuttlebutt unique is the simple idea that users should own and control all of their data.
I find this to be fundamentally wrong. After you post something on Scuttlebutt, you have no control of that data. Sure, it's stored on your computer, but it's also shared with your whole network who now have as much control of it as you have.
I'd instead put it like this:
> What makes Scuttlebutt unique is the simple idea that no one entity should control all of the users' data.
Can I chip away at that final assertion even more? If the data is easily discovered through crawling the network, and nodes on the network are less resilient than Facebook's sprawling infrastructure, you've potentially given a single attacker control over reading and denying access* to data. There will need to be protocol to mitigate attacks on the network by sharing information between nodes.
Would be great if they could set this up to work over your email account. Just add a rule to hide the data passing messages from your normal inbox activity.
"Of course, unscrupulous firms like Cambridge Analytica are also able to access some users’ personal data by finding exploits in Facebook’s policies."
The "unscrupulous firms" did not find an exploit in Facebook's policies. Facebook designed those policies so that 3rd-party developers had access to user's data, and they knew it since the very beginning.
Imagine if Mark created Facebook as an open source alternative for Myspace. Would it ever succeed ?
Good technology is not enough to replace a popular product. We need to find the next popular product. The next cool, fun product can be also an ethical one if right team works on it. It's harder than building a robust decentralized network.
Just spent about 30 minutes trying to install and connect to a hub. Ended up at a GitHub bug report with no way forward.
While SSB looks very promising, and I REALLY hope we can re-decentralize the web, SSB seems to have a long way to go to match the simplicity of getting started on a service like FB.
I set this up a few months ago and found basically nothing. I wasn't expecting much, but there was literally no conversation anywhere. Perhaps I didn't put enough time in or connect to enough shards, but after about an hour I wasn't interested in continuing.
Now that machine learning classifiers are more and more mainstream, I'd hope someone would build a system of pluggable ones you could use to dynamically block what you don't want to see.
When it comes to systems like scuttlebutt though, can't you just pick who you follow and if someone posts stuff you don't like, unfollow them?
Just off the bat, you could have feeds that handle complaints and publish blocklists that users can freely subscribe to depending on their content preferences, or just block whatever you don't like when you see it.
Scuttlebutt is "against consensus" in that the only enforced consensus is that its users are using the same basic protocol—you can block content, but that doesn't mean everyone else has to agree to it and block the same content.
Perhaps I am being dense, but I don't see a public repo with the source code and technical documentation. Is this an open source framework? What language is it written in?
I think projects like these are cool for tech nerds out there. But to the average user, unless it's super easy to use and looks pretty, they don't care for it.
Every bubble other than the own is unpleasant. Social networks need to reproduce the filters we create in real life (social, territorial, etc.) to represent human interaction.
Facebook is sometimes famously called out for creating those filters. ... although I often struggle to unfollow unpleasant (stupid/hateful/hivemind/low effort) content fast enough.
> That is just a problem of offering good filters.
True, and this is a solved problem in the fediverse. Mastodon dev team have been particularly good at implementing filtering tools at both the user and instance level (like the email filters that block whole domains used only for spam or other abuse).
We've had a couple of waves of folks banned from the birdsite turn up, get asked to set up their own instances, and after a while, you just stop noticing they're there. It's like a normal after-work drinks pub and a skinhead bar being in the same street. You occasionally walk past some unsavoury characters, but you don't have to interact with them.
> Facebook is sometimes famously called out for creating those filters.
No, what FarceBook and goOgle (among others) are called out for is creating echo chambers, not filters. The difference is subtle but crucial. In a nutshell, filters allow you to mute people who abuse you; spamming, flooding, flaming, dogpiling, sea-lioning, all the old favourites from UseNet/ mailing lists and a few new ones. Echo chambers quietly disappear the opinions of people who may disagree with you, however politely, and regardless of how many peer-reviewed citations they offer. You don't even know its happening, leading to dangerous levels of false consciousness, and uncritical partisanship.
There is no universalizable qualitative difference between filters that create a bubble/echo chamber and filters that do not. The word echo chamber and bubble are just meant to transport a value judgement against their existence. Which is why people often talk about other people's echo chamber and their own legitimate anti-abuse filters.
If you hold a non mainstream position you would probably want to teach your feeds to stop bombarding you with the respective mainstream position. A hundred years ago you did that through selecting a fitting club or reading a specific newspaper over another. Today you adjust filters.
What's creating a "dangerous level of false consciousness" is IMO just ignorance and media illiteracy. If people think their media diet is also everyone's media diet, they just weren't properly prepared for sophisticated media.
I prefer Scuttlebutt because of the P2P architecture which allows offline-first and no-backend. With Mastodon I still have to have an internet connection, and create an account on a server.
While I agree with your general premise, you might as well start picking your favorite hat condiments.
H-E-B is a wildly successful grocery store chain in Texas, and also the in-house brand for many of the products sold in that store.
The marketing slogan is "HEB: Here Everything's is Better!"
The reality is that, while it is often better than the competing chains (sometimes sadly so, killing Krogers and other chains in my area), HEB are the initials of the founder.
And B stands for Butt.[1]
It didn't even start as HEB - the original name was "C.C. Butt Grocery Store".
Note the Go implementation is effectively halted due to frustrations largely stemming from questionable choices in message layout and incompatibilities arising from JS (un)marshalling oddities that are largely hidden by the single implementation (it's easy to be compatible with yourself).
I would not classify SSB as "simple" to implement in anything but JS.
Well, the lack of a specification is a major hurdle. IMO, some of the glaring issues of the protocol could have been caught early if there had been an attempt to formalize the protocol.
That said, hindsight is 20/20, and I don't doubt there'll be some work to write a specification once the idea stabilizes somewhat, but since the current version of the protocol has been adopted by users, I think updates to it will be challenging.
That was just an example for how your data could be transferable for fully offline/airgap type uses. Its not the ordinary use case. The ordinary case is simply that your data resides on your device's storage.
So far, I like the implementation (I've checked out the patchwork client). The issue for me is the ease of getting started, and the social graph issue. Social networks are only useful to me if my friends are on it. I'm not a twitter kind of guy, I'm a facebook kind of guy and I'm not sure what the solution is when everyone else is on facebook.
> I'm a facebook kind of guy and I'm not sure what the solution is when everyone else is on facebook.
Somebody was the first person you knew who was on FarceBook, otherwise, from what you're saying, you wouldn't be on there. Be that someone for your network of family and friends, on a user-respecting platform. May the source be with you ;)
the effort to get started and the social graph issue are related. If it were easy to install and get my friends connected to the same networks I'm connected to, then I'd be way more inclined to be the first person in my network to recommend it to friends.
Today the bar is really low for 'easy' - clicking on a web link and providing some credentials. I think having a really nice introductory web experience and the ability to have the same experience on multiple devices for the same user is a must-have for this. I understand they're working on it, but in my mind it's the #1 barrier to adoption.
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.