Live data from Hacker News

Scuttlebutt, a Decentralized Alternative to Facebook

inthemesh.com

141–150 of 356 posts

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#141

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…

"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

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#142
post #134

Earlier quoted context omitted.

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

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

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

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#143
post #92

Facebook, but in javascript and giant Electron app with hundreds of dependencies, probably including stuff like is-number and is-odd

There is work underway to implement the protocol in Go, Rust, C and a bit of Haskell. Some of those are usable, but partially complete. There is no reason for the protocol to be restricted to JS and Electron.

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.

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#144

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…

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.

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#145
post #20
post #15

Earlier quoted context omitted.

What does this have to do with centrally stored data. Having data in a central store doesn't imply third parties. If the store is decentralized, then any party could be equivalent to a third party, and therefore anyone has access to your data.

> Having data in a central store doesn't imply third parties. How is that going to work then? Every single company holding your data in a central place is mining it today and selling the information to advertisers. On a distributed network you replicate data only with people you choose. Since you're not going to add a government (or an ad company) to your friend list, they won't have your data. Private communications…

> 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.

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#146
post #134

Earlier quoted context omitted.

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

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

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

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#147
post #134

Earlier quoted context omitted.

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

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

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

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

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

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

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

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

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#148

wtf were they thinking when they named it that? if any non joke product with "butt" in the name ever succeeds, I will eat my hat.

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".

Hope your hat tastes well.

[1]https://en.wikipedia.org/wiki/H-E-B

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#149
post #147
post #134

Earlier quoted context omitted.

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

I know that I sound like a broken record, but this is exactly the issue which canonical S-expressions were designed for, and which SPKI wrestled with & solved twenty years ago. The SPKI version of a message would look something like (I've removed the hash property, because I don't think it makes sense for an object to specify the hash to be used to refer to it, but one could add it back in if one wished): (message (p…

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

Re: Scuttlebutt, a Decentralized Alternative to Facebook

#150
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.

Has this changed?

Post reply on HN