Wack Playstation Sup! ๐Ÿ™Š ๐Ÿ‡ฎ๐Ÿ‡ธ ๐Ÿ is a user on mastodon.xyz. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
Wack Playstation Sup! ๐Ÿ™Š ๐Ÿ‡ฎ๐Ÿ‡ธ ๐Ÿ @HerraBRE

witches.town / SaaS critique Show more

ยท Web ยท 25 ยท 36

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

@gme @HerraBRE lol you can't run Mastodon on an raspberry pi. You need to use Pleroma for that

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

@herrabre "If you depend on other people for your healthcare and infrastructure, let alone for your judicial identity, access to legal recourse and social life offline - you will get screwed WHEN (not if) their needs and your diverge".

We always depend on each other. The question is if there are structures in place to support a peaceful transition between changes in governance and other important people. For witches.town there were no such structures in place. For other instances, there are.

@pettter Yes, of course if you are lucky enough to have benevolent governance then problems are mitigated.

The design of the tool is not neutral though. A tool designed to give admins more power plays into the hands of bad actors, a tool designed to give end-users autonomy does the opposite.

Mastodon and the Fediverse fail this test badly, the tools are geeky and technical and the design doesn't allow for easy account migration.

This exaggerates the power imbalance.

@pettter As a tool builder, I focus on the tools and their characteristics.

I am very happy if other people work on governance and policy - those matter too.

But I'm still not going to stop advocating for better tools. ๐Ÿ˜

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

@HerraBRE account migration is not desirable. It is individualistic and counterproductive for communities.

@mmn That approach is one that gives admins all the power and the users none. On behalf of users everywhere, I disagree. ๐Ÿ˜„

@mmn
Can you elaborate on that? I think account migration is a crucial feature. For a easy start people might pick a random server and later want to move to one who fits better,or their own. Without having to start from scratch. The admin tells you that they will shutdown the server, again you want to move to another server without losing your connections. The "right to move" is a key principle to establish software freedom in the SaaS world,IMHO
@HerraBRE

@bjoern @HerraBRE I'll start by ignoring the technical and social difficulties (domain name changing... causing troubles both for lookups/computers as well as humans who remember the old address...)...

What you mention first, @bjoern, is not account migration. "Without having to start from scratch" and "without losing your connections" is only the transferral of subscriptions. We could discuss bi-directional transferrals (but why would you be able to force a remote party to subscribe to a new, possibly untrusted, server?!).

The "right to move" is still there. Restoration of backed up data is however incredibly hard to do without breaking the laws of physics.
@bjoern @HerraBRE restoration of old backed up data to a new identity* (that is: the process of moving to a new identity)
@bjoern I simply wouldn't defend "the right to move". But I'd defend "the right to choose provider". One is physically impossible to do (in a secure _and_ user friendly way), the other simple as SMTP.

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

witches.town / SaaS critique Show more

@pettter @rysiek @bjoern Not really. Reproduceable builds and torrent-like distribution (or just anon over Tor) can prevent the update server from targeting individual users.

If they decide to backdoor the entire user population... well, people might notice. And that's the entire universe of software we use today anyway.

Also, aren't you the community collaboration and governance advocate in this thread? ๐Ÿ˜€

@herrabre @rysiek @bjoern The point is that you are simply reproducing the same problems in a slightly different place of the ecosystem.

@pettter @HerraBRE @bjoern ah, you are absolutely right.

We should just all get back to the Faceboogletter, since the Fediverse is just reproducing the same problems in a slightly different place of the ecosystem.

:)

@rysiek @herrabre @bjoern What? No, the point is that there are certain points in an ecosystem that are more vulnerable and more critical, and that it is perhaps not a good idea to make _every_ point into such.

That there are problems you can abstract away from most users, e.g. the ones who don't want to deal with that shit, and a federated infrastructure, protocol and standard is a reasonable way of letting the ones who _want_ to deal with those problems to be _able_ to do so, but to let others who don't place their trust in any of a multitude of server operators, including ones they have a personal connection to.

We should aim to make running a server easy, but it is _never_ going to be trivial, or have as few potential problems as running a word processor.

@pettter @HerraBRE @bjoern and yet again I find myself pointing towards serverless protocols and how easy it was running the desktop software for them, and that perhaps that's something we should be thinking about, instead of cementing ourselves in this "protocols are server-based beasts, servers are hard to manage, we should just give up on this full decentralization thing".

@rysiek @herrabre @bjoern There are different problems and applications that require different approaches. Not everything should be federated. Not everything should be P2P.

@pettter @HerraBRE @bjoern and yet I have a feeling software update servers are generally more trustworthy than most "cloud" services.

I have not heard Debian selling update users' data to data brokers. Have you?

@rysiek @herrabre @bjoern Sure, and neither did LavaBit and RiseUp and a bunch of others. However, pretty sure that the Google Android stores and Apple Store keeps track and sells your data.

The point is that you're moving the point of trust to a different place in the ecosystem, but you're not doing away with it.

@pettter @HerraBRE @bjoern but now to use Mastodon you have to trust more entities than you would have to if it were a peer-to-peer world!

And then we can fix the software distribution thing too, with stuff like IPFS and/or gx package manager.

Again, these are technical problems you are mentioning, not social ones.

@rysiek @herrabre @bjoern I can abstract away some of the trust issues by leaving them to my trusted admin. Doing that ย lets me and a hundred other users get on with my day instead of reading all the relevant mailing lists and checking alerts for CVEs, bug reports, updates, stolen keys etc.

If I want to I might run everything on my own, taking the time and effort to understand the issues, technology and people, but then why shouldn't I run stuff for my family also? For my friends?

Moreover, if there is a single package that can be compromised, that becomes a _very_ high-value target (see OpenSSL). If there are many different server admins that means a lot more eyes on any changes.

@pettter @HerraBRE @bjoern I can abstract away some of the trust issues by leaving them to my automatic software updates. I assure you most users do not read CVEs for their password managers or word processors every day.

Most users already have a version of OpenSSL on their systems, and a compromised browser is basically as bad (from their perspective) as a compromised server.

Is running a password manager (you do have one, right?) taking your time from family and friends?

@pettter @HerraBRE @bjoern why do you assume we cannot make the effort of running a single-user instance considerably (dramatically?) lower than the effort of running a multi-user one?

On a single-user instance you do not need PostgreSQL or MySQL, nor redis, nor sidekiq. A single-user instance could do away with most complexity of a multi-user instance.

Why would it be unfeasible to run a single-user instance just users run their desktop software? Where is the crucial difference?

@rysiek @herrabre @bjoern The most obvious difference is uptime.

An e-mail client, OStatus client, XMPP client, web browser, document editor, music production framework, image processor etc. need to be online _only_ when I am (with a few exceptions and caveats, of course).

An e-mail _server_, OStatus _server_, XMPP _server_ etc. need to be available _all the time_, or near enough to make no difference. I can't run it on my laptop that I log into once ever three days and expect a similar experience as if I had a VPS running 24/7, especially if the same is true of my friends and others I want to communicate with.

Of course, you could just Post It All To The Blockchain, but that has its own problems of moderation, storage, replication, traffic use etc. etc.

There are some problems for which a P2P architecture makes sense and work _very_ well. There are some problems for which it is not suited. There are even problems which are Hard(tm) to solve non-centralised.
@pettter @rysiek @herrabre @bjoern

> An e-mail _server_, OStatus _server_, XMPP _server_ etc. need to be available _all the time_, or near enough to make no difference.

That is only true because of how the protocols work.

#ssb is designed to handle intermittent connections and drop points. There is no global blockchain. There is an issue of how much to replicate and how much to miss out on, and pubs are doing maybe a bit too much work, but those things are being worked on as well, improving granularity along various axes.

For IM, sure, if you want to send offline messages your peers need to be online at the same time at some point, but for people you usually have synchronous conversations with, this isn't a big issue.
@clacke How long do you cache something that's supposed to be delivered asynchronously? If it's cached, who holds that information? If the two peers who hold this information are very seldom online at the same time, how long is an acceptable delivery delay? If magic distribution via third parties is possible, how is this information protected?

Say what, you mean that users enjoy reading and comparing fingerprints, never fail to take encryption and verification instructions seriously and also back up their secret keys in a non-ridiculous manner? Well then, I guess it's all fine and dandy. Forget I ever said anything .)
@mmn No. You discover other users through their postings and referral from friends, so key exchange is never an issue. If you do want to talk to a meat friend, then sure, they will give you their public key hash "hey here's my user id", and that's your key exchange party.