witches.town / SaaS critique 

witches.town / SaaS critique 

witches.town / SaaS critique 

witches.town / SaaS critique 

witches.town / SaaS critique 


witches.town / SaaS critique 

witches.town / SaaS critique 

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

@clacke @bjoern @HerraBRE @rysiek @pettter

That is not true for SMTP. Email can tolerate outages of days or weeks depending on configuration. It was designed in the days of servers dialling up each other to copy messages in batches.

@river @pettter @rysiek @herrabre @bjoern

That is true. But most servers will mail you annoying messages about the delays. :-)

@rysiek @pettter @HerraBRE @bjoern
There's an example of a peer-to-peer world where you trust nobody: Ethereum.
And as we've seen, people are not well suited to live in such a world, because they:
- make mistakes
- get scammed
- are generally bad at expressing laws with code, let alone expressing social norms with code

@Wolf480pl @rysiek @pettter @HerraBRE @bjoern
oh and there's another -

- the infrastructure gets left to rot.
python client? Stuck on ancient python 2 deps.
4 years and still no client in debian. GPL versioned clients relicesned / ported to non-copyleft permissive versions at least in 2 cases.

like #ripple, I fear ethereum's achilles heel is that the incentives to keep the system working are just not there

@jeffcliff @Wolf480pl @pettter @HerraBRE @bjoern and another one -- when DAO thing got ransacked, the devs decided to block a particular address.

Which is completely against the core values Ethereum and other blockchain-based systems are supposedly built around: namely, that no single entity has control, and that individual users cannot be singled out.

@rysiek @jeffcliff @pettter @HerraBRE @bjoern AFAIK there was an option --opose-dao-fork or something, and the GUI would display a popup if you want to fork or not. That's how ETC (EThereum Classic) came into existence.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!