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.
only capabilities
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[0] 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[1] 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.
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.