I want to participate, but periodically I check https://www.scuttlebutt.nz/faq/applications/multiple-devices... and it hasn't changed, and for me, having a single device to which the entirety of my identity is tied is a non-starter. Even so, the tech seems interesting, and I hope that limitation goes away one day.
That will quickly render the web viewer useless. I wonder where and how that decision was made. There was a previous discussion about this a few months back that I saw but the consensus then was not to go ahead with it. Obviously the way overridden along the way.
But no-one's in charge. Someone else could make a web viewer that shows all public posts without opt-in. (Public posts on SSB are signed cryptographically but not encrypted.)
The other question is: is this a good precedent to set for the community. I'm imagining a lot of less tech-literate SSB users could interpret this opt-in feature as a guarantee of the privacy of their SSB posts, which it certainly isn't.
> what's the point of having a web viewer at all if 99% of users use default settings and don't explicitly opt-in?
So you can choose to share your posts on the web.
> The other question is: is this a good precedent to set for the community.
I think it is: thinking about whether other people would want you to republish their content; asking first; consent. You can, but should you?
> I'm imagining a lot of less tech-literate SSB users could interpret this opt-in feature as a guarantee of the privacy of their SSB posts, which it certainly isn't.
Yeah, there's a lot of misconception. I don't think the SSB ecosystem is worse than the alternative centralised services here though. For example, I think some of them claim that “your message will be deleted after x minutes”, but they forget that someone could just take a photo of the screen
Public means public, and it's always technically possible to republish a public message. It's always been controlled by social conventions not technical means.
I think it's a good thing that the SSB community is asking moral questions about how should you treat other people, and not just questions about what the tech makes possible.
Of course, but that doesn't change their authority. They have a website, a Github organisation; it is the public centralised face of the software development efforts, no matter how jokey the participants consider it nor how fluid the membership.
Solutions like git-ssb are an improvement, but it's a hard problem to solve: when a stranger asks you for the code for the web viewer, is the correct answer just to give them what you personally run? If so, that seems similar to what the SSBC is doing.
I'd personally love to hear more solutions to this sort of problem.
Solution ive seen many of the serious users use is raspberry pie running patchfoo at home and connecting to your rpi.
Added hustle and you are basicaly centralising it for yourself.
re size: you really don’t need _everything_ locally all the time. You can delete unused blobs easily, which take up most of the space.
It’s all very implementation specific as well.
This doesn't work with multiple devices, since they'll be two different logs. However, there is ongoing work to support multiple identities. One identity could broadcast that another identity is a "sameAs" - causing friendly peers to sync with the other identity as well.
Personally, I haven't found this to be a problem. I find separate identities less distracting. (My favorite reason to use SSB is that continuous syncing is not an expectation.)
A luxury not shared by marginalized persons, such as closeted gay or trans folks, political dissidents in repressive countries, or conservatives in Silicon Valley
Their plan is to support this at a client level: you create multiple identities with metadata indicating that all are the same person on different devices, which clients can then use to group them appropriately in whatever way makes sense.
UX wise, it may make sense for some clients to obscure this architecture from new users somewhat and treat them visually as the same identity, but that's down the line (and I'm sure some purist clients will never want to do this).
Skip to 11:45 into the video, the algorithm/cryptography for it isn't that hard either: https://www.decentralizedweb.net/videos/talk-better-algorith... you could do it in SSB without needing gun!
But now you just kick the can back. You still have to have an account that manages the device keys, and you certainly don't want that locked down to a device - unless that device is the user's brain.
So either way, you're still gonna have to use a system to manage it that looks 110% like the MIT Open Source security/cryptography code anybody can rip from us.
They need to mutually confirm it. If keyA says sameAs keyB, and keyB says sameAs keyA, then they should be considered merged.
accept this, find peace
If you guys do this, you'll shoot your user adoption in the foot.
Do you really think XYZ millions of users moving from FB in the next decade, when they come to SSB or NAB, are going to choose the one that is intentionally more complicated/confusing/harder-to-use?
Get passwords working in cryptographically secure ways and the world will be at more peace.
i don't care about millions of people. mass adoption is fine, but i don't care about the people who already have internet, smartphones, and need convincing to drop their shitty spyware android device. i care about the billions of people who are coming online in the next 5-10 years. i'm developing a stack that integrates hardware, software, and p2p/mesh protocols to compete directly with telcos and OEMs.
when you include hardware security, the user experience of per-device keys is much nicer. you need a passcode that is used to protect your device-entangled key and that's it. new devices pair like bluetooth, securely handshake, and publish `sameAs` depending on the type of device. users don't need to worry about anything beyond the device passcode. projects like dark crystal make it easy to generate and distribute an emergency key that can be used to restore access to your devices if you forget your code.
Is this a feature of SSB or a bug? I mean once I'm in the network and well-entrenched, I could see it being a feature. But how do I even get to that point? (Oh and does Manyverse address this at all? Sorry I don't have Android.)
Manyverse is the first SSB app that implements DHT invites: https://gitlab.com/staltz/ssb-dht-invite and the plan is to make it easier for anyone to invite anyone else, so that we rely less on a single "cluster". We want to get to the point where there are isolated islands of SSB networks.
But the point you seem to be talking about is also discovery, e.g. something like a "search" feature for friends. We don't have any idea in mind for that, and we also question whether that's necessary at all, specially as we seek to bring this app to countries with limited or no internet access.
> Manyverse is the first SSB app that implements DHT invites
Ok - this is cool! I can see how SSB/Patchwork/Manyverse could be used to replace old invite-only forums (which I've enjoyed with 'real life' friends in the past.)
So, yes, I do think discovery is a huge problem for SSB (and Dat, too) because one of the blissful (and terrible) things about the Web is that arbitrary people can find each other. This seems to be an even bigger problem now that certain networks are massive in scale - so the 'island' approach is one that excites me. Not sure about 'isolated', though. With Patchwork, I begin to wonder why I'm able to read things that I can't respond to - and then I realize that I probably don't want to anyway. I may just not understand the whole thing tho. :)
Can also be installed via Dat Installer https://github.com/staltz/dat-installer
(yep that's right, you can install a decentralized app through a decentralized app)
There now is a python and Go base and rust is starting as well.
I haven't checked since, but unless the situation has substantially improved since, it's no surprise that the JS implementation is the only one out there.
The SSB protocol and feed database are both very flexible and can be used in the way you want if someone builds the app for it.
hmm.. at it's core it's just a database (that syncs across the friend graph), you might find cel's work on git-ssb and ssb-npm-registry interesting. you could just as well make something like discourse ontop of it.
we are currently discussing something more _groupware_ like to remove the dependency on github for issue tracking.
 https://dymaxion.org/essays/briarvision.html previously discussed at https://news.ycombinator.com/item?id=18027949
There seems to be a large overlap between the SSB and Cabal communities.
Scuttlebutt is a social network platform where each uxer has a personal diary where each page is a signed message that links to the previous page. to receive updates on someone's diary, you follow the person. on each page, content is free-form. the most common message type is 'post', but there's a chat app (similar to Cabal) that uses message type 'scat_message': https://www.scuttlebutt.nz/applications#scat.
Cabal is a chat app, built using the Dat protocol (https://datproject.org/). Dat has a similar architecture, except the diaries (sigchains) are centered on content rather than people. so to receive updates on a diary, you follow the _content_, which in Cabal is a chat group similar to a Slack group.
Ed: looks like https://github.com/ssbc/scuttlebot/blob/master/README.md has a bit more meat. Still happy to hear any comments. Especially I assume any recipient can prove to a third party that someone said something?
> I assume any recipient can prove to a third party that someone said something
All public messages are signed with the author's key, so any third-party can verify it.
Private messages are different, though. You need one of the recipient / sender's keys to decrypt that, and so for a third-party to verify it they would need one of those private keys.
You can now generate an unbox key for a private message send it to a non-recipient for them to be able to access the message, which is really cool. No private key sharing necessary!
So if I say: "let's fight racism!" and you later decide to collaborate with a (now) racist government - you could prove (not merely allege) that I should go to the gulag?
yes, on-chain messages are designed to be "on the record" (https://viewer.scuttlebot.io/%25G7BjZsZr02TPAoIeD%2Bw3WgiAbi...), where the game theory is of an infinitely-repeated game (https://en.wikipedia.org/wiki/Repeated_game#Infinitely_repea...) where participants have verifiable knowledge of past game activity, which is useful for trust-based coordination.
our plan is to eventually add a side protocol for off-chain ("off the record") messages which re-use the same cryptographic identities, for all your other conversations. :)
Does it use any kind of DHT like Kademlia? I know you want to avoid singletons but are there any hubs that are DHTs or what? How does discovery work? And do you support Web Push?
The DAT link is dat://520a00daf0a309bef7722b3f3338854e9da667d01e48dc7b83b118d86354d6d3
The DAT Installer is here: https://github.com/staltz/dat-installer
(Also, this project does look like it's been going on since mid-2014, so I'm not entirely convinced the lack of an iOS client is due to a lack of time. A lack of available/interested iOS developers seems more likely.)
"Unfortunately, your email to GitLab could not be processed. We couldn't find the project. Please check if there's any typo."
Also, are issues turned off on the repo?
I'm mainly making the point that their landing page has done a pretty bad job of explaining and selling the product.
welcome to the 'verse! ️️
I am sorry to ask these (I guess mundane) questions here but I tried the docs and it isn't really clear. Also patchwork desktop app brought my laptop to a standstill so couldn't explore much.
- the pub will post a message to follow you
- you will post a message to follow the pub
- you will post a message advertising the pub on your feed
basically this mean you will become connected to the pub's social graph (by following the pub) and vise versa the pub will replicate your messages (by the pub following you).
also to note, in the future we will change the pub invite story: invites are directed from one user to another user and pubs are only a messenger (%LMYARKcJ5/HVrkfyGo0oSV4j/whFmpeiJlQnvPw53PE=.sha256), and pubs will become just another device controlled by a specific user (%Gwqklkj0b2CBT5tPiz5170NWsPp3xiuLbOImEaG/e+4=.sha256)
happy to answer any questions! also, i know the initial sync is pretty intense at the moment (joining most public pubs means joining an active community with years of content!), but once it's done it's done, later you only sync what you missed since you last sync'd.
Can I choose to sync just the new content since I joined? Or since let's say June 2017? And can I clear the previous content synced on my device? If nothing then, let's say, for need for free disk space.
Also, I have installed the Manyverse app on my Android phone (hoping it would not be as resource intensive as Patchwork) - but shall I have do everything all over again if I ever to go for a desktop app or any other app on any device (as it seems from other comments in this post) - every invite being added again and so on?
(Edit) And Manyverse is another decentralised app that is using ScuttleButt protocol, right? And the Android app is a way to access "just this app/social network" on the SSB network - or not on a network really since it's P2P. Did I get it right?
I have watched the video and it made things a lot clearer and the heartbreaking story was touching :) But now I think Manyverse might just be a "pub" on SSB :)
at the moment no, but it's likely we'll move content off-chain (%QJEpN8LN1t3BrIkUQ3WoOMWRsMArbVUZCpTeBYcuqfw=.sha256) so you would only need to sync the signature chain metadata, then could choose what content you want to download or delete.
> But now I think Manyverse might just be a "pub" on SSB
Manyverse is a mobile app on SSB, much like Patchwork is a desktop app. it uses all the same peer-to-peer network, including the existing pubs (as in there are no pubs specific to Manyverse).
> shall I have do everything all over again if I ever to go for a desktop app or any other app on any device
if you want to use both Manyverse and Patchwork, yes they will be separate keys each with their own feed, to be merged as the same conceptual identity, see this comment: https://news.ycombinator.com/item?id=18067100.
Also, you could join as many "pubs" as you like - based on your interests. You'll start receiving feeds from other people who share the pub, and their friends as well.
Does the sync allow for deletion too?
there's talk of moving message content out of the sigchain so you could "delete" (ask your peers to delete) a post: %QJEpN8LN1t3BrIkUQ3WoOMWRsMArbVUZCpTeBYcuqfw=.sha256
Other systems all use some variant of immutable data structures (hashes, append-only logs, DAGs, etc.) vs CRDTs which can do immutable OR mutable data.
An authority could shut down a pub, or stop a feed from propogating if they really wanted to, over a channel they control. But they can't really stop every single comms channel.