Mr. Big Red Engine ๐Ÿ™Š ๐Ÿ‡ฎ๐Ÿ‡ธ ๐Ÿ 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.
Mr. Big Red Engine ๐Ÿ™Š ๐Ÿ‡ฎ๐Ÿ‡ธ ๐Ÿ @HerraBRE

witches.town / SaaS critique Show more

ยท Web ยท 13 ยท 24

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

@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 indefinitely. by your social graph. as long as it takes. cryptographically authenticated append-only log.

@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

@bjoern @HerraBRE I don't think so. In the old days "everyone has it's own little computer" would have sounded hopelessly optimistic given the complexity of mainframes.
@herrabre @bjoern Comparing running a local app with running a server has to be one of the more weird comparisons I've seen lately.

@HerraBRE @pettter @bjoern indeed it is! Try running it with gpg-agent! ;)

Okay, okay, that was uncalled for. Apologies. <3

@herrabre @bjoern ...no it isn't? Have you changed it from being an e-mail _client_ to being an e-mail _server_ while I wasn't looking? Shouldn't you update the webpage to reflect this rather major change?

@pettter @bjoern You sound sarcastic and hostile, am I misreading?

is an e-mail client and a web server. It's both.

I'm almost done integrating push-button PageKite and Tor HS functionality, so people can access the UI remotely, which will allow people to access a running Mailpile remotely, e.g. from their phones.

@herrabre @bjoern Is Mailpile intended to be an e-mail client or an e-mail server?

Are you proposing that people should be able to run their own fediverse instance or their own fediverse clients as easily as their own word processor?

@pettter @bjoern Hell yeah!

That would be awesome!

I already answered your Mailpile question, it's an e-mail client and a web server. Sorry if that breaks your brain.

@herrabre @bjoern >ย Hell yeah! That would be awesome!

That's not an answer. The question is

Are you proposing that people should be able to run
a) Their own fediverse instance, or
b) Their own fediverse client,
as easily as their own word processsor?ย 

They are at radically different levels of complexity, risk, attack surface, need for uptime and backups, etc. Hence the question.

>ย I already answered your Mailpile question, it's an e-mail client and a web server.

Glad I didn't misunderstand you. Mailpile is an e-mail _client_ then, and thus irrelevant to the topic.

>Sorry if that breaks your brain.

Why the casual insult?

@pettter @HerraBRE @bjoern consider stuff like Twister -- a serverless social network built on top of BitTorrent and (wait for it) blockchain.

There are no servers. Everybody runs their own stuff. The question becomes one of interface usability, not server management.

Attack surface against a single user instance running locally? Hey, at least there is literally no way to phish it.

@rysiek
Subject: IMPORTANT TWISTER UPDATE
YOU MUST INSTALL THIS .EXE/.APK _NOW_ OR YOU ARE VULNERABLE TO COMPUTER VIRUSES. CLICK _HERE_ TO DOWNLOAD YOUR UPDATE

@mmn how is this not a problem we are already experiencing with browsers, or Mastodon/Fediverse desktop/mobile clients?

I.e. your suggestion is that it would replace one problem with another. My response is that the other problem we already have anyway, so it would effectively remove one kind of attack.

@rysiek My point was merely to indicate that users who are their own admins must also at all times be alert and in a well-functioning mindset. Or they might end up being drunk or sneezing while trying to configure their local server and accidentally break everything without any clue of how to put it back together.

Communes ftw.

@mmn my feel is that most people in this discussion came in with assumptions coming from running large, complicated, multi-user systems that have a huge attack surface and complicated threat model that includes malicious users.

With a single-user instance a huge part of this complexity goes away, completely. There is no "potentially malicious user", there is just *a user". There is no "admin account takeover", since there is... just one user. And so on, and so forth.

Different assumptions.

@rysiek @mmn

I really like the approach and even if I'm not sure it would work.

What I like most is exactly the challenge to the status quo.

Here a similar proposal you might like: per-cloud.com/

@mmn why would they need to "configure their server"? What would they be configuring? Database is not a thing, NoSQL store is not a thing, user management is not a thing, etc, etc.

They need to have Internet connection, and perhaps dynamic DNS server API for protocols that require regular domain names.

For peer-to-peer even that's irrelevant.

@rysiek Users need to back stuff up. If they don't they'll inevitably lose everything. That is not user appealing.
heh. twister and ssb take care of nearly all of the backing up, you just need to save your identity key pair, the rest can be recovered from the network. that's the beauty of truly distributed systems. federation is a step towards decentralization, but for the very concerns you raise, I'm pretty sure it's not a step in the best direction
@lxoliva So with Twister I have to store the distributedly Backes up Chile pornography? And if someone's backup is badly protected, I can _become_ that identity by just loading it on to my local client? Sounds like a system I don't want to use for my everyday social activities.
you don't have the secret key to become that identity, and without it, you can't decode the torrents you're holding.
you're better off than running a server of any of the federated networks and finding users are communicating just the same stuff on it. what kind of nonsense argument is that?

@rysiek I think Urbit is supposed to be kinda like what you're describing

@sonya FreedomBox, too.

But I'm these are small servers (dedicated hardware) that are easy to set-up.

I'm talking about making the software underlying the Fediverse (and other things) so easy to run that people would just run it like any other program on their desktops.

@rysiek yup, that's how Urbit is intended to work

@sonya I described two separate things. Can you be specific about which of them are you referring to?

@rysiek this bit is what sounds like urbit โ€”ย personal server + frontend

> I'm talking about making the software underlying the Fediverse (and other things) so easy to run that people would just run it like any other program on their desktops.

@sonya from what I read on Urbit's site it's supposed to be a personal server (I am reading this as a hardware device like FreedomBox), though.

@rysiek oh no, it's not hardware. it's more like "here's software that will turn your laptop into a personal server and make it user-friendly to manage even if you're not a sysadmin"

that's the pitch, anyway. I don't know how well the product lives up to it in practice

@sonya aaah! Now I get it. Sorry, made some weird assumptions for no good reason.

Thanks for the patience in explaining!

@sonya
@rysiek
I feel like that would actually be counterproductive, though: if it were so trivialised that servers popped and died within hours, the churn would create lots of server-noise and seriously confuse new users, too. "My friend joined yesterday but I can't even see her stuff. This is garbage!" (Your friend closed her laptop)

@pettter @HerraBRE @bjoern what completely flabbergasts me in this discussion is that instead of asking "how can we make this happen", most people seem to be looking for reasons this would never work.

I feel this approach is not going to move us forward.

I also feel that (quoting Eben Moglen, I think), the server must die to save the web. As long as we have servers, we will have centralization.

Peer-to-peer, end-to-end principle (in the revolutionary, "serverless" sense) is what we need back.

@ebel @pettter @rysiek @herrabre @bjoern

> Just as Systematic Colonization was developed to establish the capitalist mode of production in the colonies, anti-disintermediation was [developed] to colonize cyberspace. The basic strategy of anti-disintermediation was formulated by economists like Carl Shapiro and Hal R. Varian. Their influential book Information Rules encourages platform owners to pursue "lock-in." As Varian explains, "Since information technology products work in systems, switching any single product can cost users dearly. The lock-in that results from such switching costs confers a huge competitive advantage to firms that manage their installed base of customers effectively."

[ . . . ]

> Central to the counter-anti-disintermediationist design is the End-to-End principle: platforms must not depend on servers and admins, even when cooperatively run, but must, to the greatest degree possible, run on the computers of the platformโ€™s users. The computational capacity and network access of the usersโ€™ own computers must collectively make up the resources of the platform, such that, on average, each new user adds net resources to the platform. By keeping the computational capacity in the hands of the users, we prevent the communication platform from becoming capital, and we prevent the users from being instrumentalized as an audience commodity.

TL;DR: Kill the server-web as the backbone of personal communications.

#ssb #p2p

@ebel @rysiek @pettter @HerraBRE @bjoern @galaxis

This has been one of the most interesting convesation I've read so far in Mastodon.

You are touching key arguments for the future of internet.

I'd like to add some considerations that might foster the discussion towards a deeper research (I'm not even sure Mastodon is the right place for this sort of discussions... but here we are... let's go!).

@ebel @rysiek @pettter @HerraBRE @bjoern @galaxis

First

Why you all accept the premise that people should not be able to setup a server?

I think we are not much different from scriban in the ancient Egypt: we know how to compute as the knew how to write, but that's not going to endure and we should all work to make everybody able to program in the same way we are.

It's not our knowledge that is power, it's their ignorance that make them weak.

Our goal should be to loose our power.

@ebel @rysiek @pettter @HerraBRE @bjoern @galaxis

So instead of making everything easy to use, we should make everything simple (which is entirely another thing) and teach everybody to compose that simplicity.

Just like people are used to compose words in a piece of paper to write a mail or a romance.

But just like it's not easy to write or count, It's not easy to program.

We just have to find the proper way to teach everybody how to do so.

@ebel @pettter @HerraBRE @bjoern @galaxis

Second

What if the problem is not just the client/server model (with all its protocols), but the real-time availability assumption?

@rysiek proposed an heretical approach: let's try single user machines. I'm not sure it would work, but to build and sell such machine could really be a business model, and I frankly think it should be explored.

I propose (yet) another heresy: why do not remove the assumption that the node must be available at any time?

@shamar @rysiek @herrabre @galaxis @bjoern @ebel My counterquestion is why do you want everything to conform to a single model? Why not have some P2P, some federated, some centralised services?

It should be _as easy as possible_ to run and configure various things, in particular it shouldn't be hard to set up a server for a group of friends to share files, to voice chat etc, or even for yourself to publish things and gather limited information from a designated group, or even the public.

However, if you are opening more general communication to work with _anyone_, especially if you are also somehow _storing_ and _redistributing_ said communication, then there are going to be Hard Issues that need careful thought and consideration, as there are no going to be no easy and Obviously Correct answers.

@pettter @rysiek @HerraBRE @galaxis @bjoern @Shamar I'm not really sure what you're advocating. We already have good centralised and federated systems already. We are lacking a lot of decentralized alternatives.

It would be great if programming was easier to use, or servers were easier to set up. But relying on billions of people to do it won't work IMO, we'll end up with what we have now, centralized servers.

@ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

I'm not advocating, I'm proposing an alternative perspective to explore.

I don't like to renounce without fighting: you know how to write and count just because somebody else, decades before, said it was possible.

Also I'm not stating that we should have one single model, but actually I think that a better model will emerge and (if not destroyed by corporate issues) eat all the existing ones.

Does it worth the effort to find one?
I think so.

@ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

How would you design a #network #system if you cannot assume each node is continously #available?

Can we turn partitions (in #CAP theorem terms) to a feature to exploit instead of an issue to address?

For example, what if the sender host the message until the recipient become available?

What if the message is encrypted from the start with the recipient public key (one time for recipient).

@ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

How can the recipient know who has outgoing messages for her when it goes online?

What if the recipient authenticate to the sender to get the message?

I'm not saying it's easy! ๐Ÿ˜‰

@hhardy01 @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

While I'm actually trying to reinvent a network protocol (inspired by #9P2000) that would be somehow pertinent in this discussion, I was more exploring the idea of a more peer to peer network inspired by my favourite social application: email.

But also something that could serve hypertexts from a smartphone.

A smartphone cannot be always connected, so when you want to get the page you have to request and wait to be served.

@hhardy01 @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern @alanz

What if you had your public webserver in your pocket?

How would the web be different with this sort of asynchronous distribution of contents?

How would we design caching? Would we?

And what about encryption?

@Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern @alanz

Sendmail or any other mail server that works like it, which is just about everything that came after the u* protocols will do caching just fine.

Mail encryption is fairly straightforward with PGP/GPG.

@hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern More like FIDONet and amateur radio packet BBSes. These are all solved problems, if you're willing to dig far enough back into history. TCP/IP has utterly *destroyed* the knowledge accumulated in administering more 'primitive' networks (I put in quotes, because IP is, in many ways, more primitive than some BBS networks were).

@hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern
It pleases me that we're having these debates, because it means we're struggling as a community to relearn the lessons. It'll be interesting to see how they're applied to contemporary network interconnections, and what new applications come from them.

@vertigo @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

The first packet radio was ALOHANET which was a hub and spokes model.

As far as packet radio leading to not-always-connected TCP/IP, the history is KA9Q -> SLIP -> SLFP -> PPP .

@hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern KA9Q has nothing whatsoever to do with packet BBSes, except insofar as his packet driver software was often included in other BBS programs as gateways to the commercial internet.

@vertigo @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern This seems similar to the conversation we (Vertigo & I) were having yesterday about everyone building on top of layers of abstraction once they exist. X.25 and AX.25 are both connection-oriented protocols that cover layers 2 and 3 of the OSI model and give you an interface that behaves like a serial port. UUCP and FIDONet ran directly over serial connections and could use modem or X.25 over a modem.

@seanl @vertigo @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

ALOHANET was the basis of ETHERNET, which was essentially packet radio over coax.

@seanl @vertigo @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

The good thing is that all these old protocols still exist in any SysV or BSD type system. Such as Linux. It's perhaps surprising that I still go to my original SysVR4 ATT books for inspiration.

@seanl @vertigo @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

Also you can find used old O'Reilly books about old things I mentioned such as majordomo and before that listserv, and uucp.

@hhardy01 @seanl @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

I have to admit that my experience about networking is completely built upon IP.

So I have no memory of radio protocols and bbs.

So for sure I welcome any isbn or link about these techniques.

However some of the constraints that led to those solutions have gone.

We should take each of these protocols (including ip based ones), list their features and their issues, and list the constraints they were facing.

@hhardy01 @seanl @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

With that knowledge we could list the constraints WE are facing, debate a little about which constraints are accidental and which are structural, and then design better alternatives.

My bet is we would design something entirely different from the past, just because we have more bandwidth, faster connections, cheap disk space and ram, and a lot of processing power.

@hhardy01 @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern I think we should just try different things in an attempt to make incremental steps rather than trying to reinvent the wheel. I would like to see large scale networks built on BATMAN and ad hoc WiFi. One of the major things that's gotten in the way is that Android doesn't support adhoc without root and inconsistently even with root.

@hhardy01 @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern And I think Secure Scuttlebutt has a lot of potential for handling the inconsistently-online-node situation.

@seanl @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

If we want it like email then SMTP is perfectly fine with not always there connections.

@seanl @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

Why not set up majordomo;your mailing lists are your "newsgroups," SMTP is the transport, and modem mail clients will render html fine and bang you are done.

Why reinvent the wheels?

@seanl @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

BTW I built the majordomo as an asynchronous social media environment for the DARPA/SME funded CONDUIT PROJECT back in 1995. Sendmail+Majordomo + hypermail as the web interface.

Easy as pi and so simple. Even though we were in the age of make clean; make depend; make; make install. It was so easy to transport because everything went into /usr/local/etc as God intended; no evil pkg mangler to POSIXy strew things about.

@seanl @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

Pretty sure I used ncsa httpd though conceivably apache since it came out that year.

@seanl @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern
There hasn't been a release of majordomo since 2000. There is a majordomo 2.0 fork as part of openbsd.

Mailman is mostly back compatible to majordomo but I've not used it.

@hhardy01 @Shamar @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern I'm a fan of software that only gets security fixes and not new features, since new features introduce new vulnerabilities & new bugs.

@seanl @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern I like this philosophy a lot. I don't mind new features as long as they're justified by actual customer demand, and not just "keeping up with the Joneses". Bug fixes and security patches are definitely more valuable to me.

@hhardy01 @seanl @Shamar @vertigo @ebel @pettter @HerraBRE @galaxis @bjoern I dockerized Schleuder3 (GPG-enabled mailing list manager) some time ago. Need to set it up again.

@hhardy01 @seanl @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

As an aside, one of my friends works at Michelin R&D.

He's literally paid to invent new wheels!

@hhardy01 @seanl @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern Having experience in setting up Majordomo (built and ran two ISPs back in ye olden dayes), I distinctly remember it being a BEAR to set up and make secure.

@hhardy01 @seanl @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern
BBSes are substantially more mature in the ease-of-installation and ease-of-security fields. I've considered self-hosting my own mail via a self-hosted Citadel BBS for some time now. Packages are trivially available, and it can double as a mailing list and web forum if people were so inclined to create accounts on it.

And by BBS, I'm talking about stuff like RemoteAccess or Citadel, not phpBB. ;)

@Shamar @seanl @vertigo @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

Lick saw it all the future of the net up to the Intergalactic Computer Network of his memo from the future in 1962.

And this:

bit.ly/2El1jS9

@hhardy01 @vertigo @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern I still occasionally use AX.25, mostly for APRS which uses unconnected frames. I haven't yet had a good reason to use the kernel's AX.25 support. It would be fun to set up an AX.25 BBS using soundmodem so Linux is involved all the way down to the audio modulation.

@seanl @vertigo @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

So the history of using modems for networks goes to WHIRLWIND -> SAGE -> CTSS -> MULTICS -> UNIX

@hhardy01 @seanl @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern Don't forget SNA and other branches of development on the IBM mainframes. X.25 (and thus AX.25) is a direct descendant of SNA.

@seanl @vertigo @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

Then UNIX went to system 7 before the numbering started over with Roman numerals at III.

In better timelines (not ours unfortunately) modern systems are probably based on Plan 9 and inherently distributed. :)

@hhardy01 @seanl @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern I still have my heart set on running Plan 9 on my homebrew computer designs. I wish I were smart enough to port it myself.

@seanl @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern The kernel's AX.25 support is pretty horrible, actually. I wouldn't recommend it unless you had clear line of sight to your destination node. My experience using it (while dated) is that the slightest packet loss will result in unsable connections.

@seanl @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern At the time, yes. Attempting to run telnet over AX.25 to demonstrate remote logging during a Field Day. I was successful, but it was unbearably slow due to needless competition between TCP and AX.25 both trying to retransmit to overcome noise.

@vertigo @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern But you always had a very small number of connections available, maybe even just 1 at a time. So everything was done with queuing and batches and store-and-forward.

With TCP we can now have a huge number of connections, and the Internet means most nodes are online all the time. So everything breaks if nodes go offline, or worse if you have non-transitive connectivity, which none of the prior protocols cared about.

@vertigo @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern TCP isn't the modern equivalent of a modem line even if at its lowest level it looks like a serial interface. It's the equivalent of a full mesh of hardwired serial connections, because the circuit-switched connections are so quick and reliable to set up.

@seanl @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern If you treat each connection as a virtual cable, which is the intent, then connections can come and go at will as long as the end to end software implements store-and-forward. Indeed, your host OS *already* implements SaF semantics, but on an IP packet by IP packet basis. TCP's retransmit window depends on this.

@seanl @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern
The mistake is assuming everything runs on reliable copper. End software can avoid this trap by implementing its own SaF semantics. I'm successfully implementing this for IoT code running at work now, with great success.

@vertigo @hhardy01 @Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern Another advantage of using SaF is that anonymity is MUCH easier to achieve if you aren't trying to minimize latency the way Tor and I2P do. Speaking of which, Freenet and GNUnet don't really care about intermittent connectivity, but I'm not sure they can handle non-transitive connectivity. I think cjdns can handle that, but it doesn't provide anything to help you with intermittently connected nodes.

@Shamar @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

You would set up a network which is not always connected, like USENET.

@UberGeek @ebel @pettter @rysiek @HerraBRE @galaxis @bjoern

I really like the SMTP architecture (I already said that email is my favourite social application? I really mean it!), but it was designed in a different age.

I'm pretty sure that would build something different in the current age of huge bandwidth, fast connections and cheap hardware

@ebel @pettter @rysiek @HerraBRE @bjoern @Shamar @UberGeek Haha. SMTP servers hated to queue mail. Storage was slow and expensive, and dealing with large queues (and then getting rid of them) was a form of art. At least until postfix showed up.

@galaxis @ebel @pettter @HerraBRE @bjoern @Shamar @UberGeek "solved that" means "it used to be a problem, now it's not", and does not necessarily mean "it was never a problem".

Currently in e-mail this is not a problem.

@rysiek @galaxis @ebel @pettter @HerraBRE @bjoern @UberGeek actually I've always wondered why clients use imap/pop instead of running a smtp server that accept the mails for the users and put them in their folders...

ISP's smtp servers would just be there to queue.

I guess there's a practical issue I'm missing right?

I know that such approach would mean a more fine-grained mx domain hierarchy (one name per pc) but I guess the problem is more something about disk space... isn't it?

@Shamar @rysiek @galaxis @ebel @pettter @bjoern @UberGeek The practical issue you are missing is most clients do not have a public IP address, so the ISP server cannot reach them.

There are fewer public IPv4 addresses than there are humans, and they are not evenly allocated.

Also, firewalls are a thing, so even if we adopt IPv6 tomorrow the issue will remain.

@HerraBRE @rysiek @galaxis @ebel @pettter @bjoern @UberGeek

Good points, but not sure they are unsolvable.
My ISP could serve a reserved unused ip as the MX record for shamar.mx.isp.com.

Meanwhile a secondary MX record get used to enqueue mails.

When I connect (while I'm connected) the ISP update the MX to point to my actual ip.

At that point the queuing mailing could deliver the mails to me. Or I get them with On-Demand Mail Relay.

Just my first though...

@Shamar @HerraBRE @rysiek @ebel @pettter @bjoern @UberGeek UUCP would solve that problem right away, since UUCP routing doesn't depend on DNS ๐Ÿ˜‰

@Shamar For domain-addressed email, you'd basically have a static mapping from the recipient domain to a UUCP node name on the system that batches up mails for UUCP transport.
I don't think it's something you'd want to build on today.

@Shamar @HerraBRE @rysiek @galaxis @ebel @pettter @bjoern @UberGeek

So first option is use a dynamic ip such as freedns.

Second option is use a smarter host as primary in your MX records and then use imap, smap, rsync, or scp to pull or push the mail to the final mail server. Unless you are using scp you want to use an ssh tunnel or vpn to secure your link.

I once had to fix broke machine on a production line in china. I sent them a disk to boot that let me tunnel the great firewall port 80.

@rysiek @Shamar @galaxis @ebel @pettter @bjoern @UberGeek Oh yes, I was just answering the specific question about why legacy SMTP only reaches the server and the "last mile" uses POP3 or IMAP (which are client initiated and can traverse NAT, not server initiated).

I've experimented with P2P SMTP over Tor, in the context of . I think it has interesting potential as a way to "upgrade" the e-mail to an anonymized P2P architecture, without inventing any new protocols.

@Shamar @ebel @rysiek @pettter @HerraBRE @bjoern @galaxis My premise: we should rarely need to setup a server.

And thankfully that day draws ever nearer.

@Shamar @ebel @rysiek @pettter @HerraBRE @bjoern @galaxis I'm thinking peer-to-peer.

If I was thinking of the cloud, then at least the cloud providers would still need to configure servers.

P.S. I'm not entirely sold peer-to-peer can or should do everything, but we certainly can get close.

@alcinnz @ebel @rysiek @pettter @HerraBRE @bjoern @galaxis

I do not yet see much improvement towards a p2p web... but actually @alanz has been the first to point me to scuttlebutt, so maybe I just missed the progressions.

Last time I've found something really promising in P2P (that eventually did not catch up) it was a Tannenbaum project for encrypted Friend2Friend networks.

@Shamar @alcinnz @ebel @pettter @HerraBRE @bjoern @galaxis @alanz here's a couple of other p2p communication projects that might be interesting: Twister (BitTorrent/Blockchain based social network), Tox (encrypted p2p IM and audio/video calls), Briar (end-to-end encrypted Tor-based IM with forums and blogs), Retroshare (too many features to even list)

@rysiek @alcinnz @ebel @pettter @HerraBRE @bjoern @galaxis @alanz

I'm skeptic about anything that contains the #Blockchain word (too much energy, world cannot afford that), but really thanks for the other reference, I'll look at them to!

@Shamar @rysiek @alcinnz

Agree about #blockchain. #IPFS has an interesting idea: Filecoin. It's is 'earned'/'mined' by storing data. (sort of byte-seconds) The 'work' isn't CPU intensive useless hashing algorithms. I think you could then buy/sell these FileCoins if you want to store things, or if you want to make money from spare storage capacity.
It gives an economic incentive to things you want people to do (store other people's data).
But it's not available/launched yet. โ˜น

@ebel

And holochain seems to be similar, but more general, in trying to encourage edge computing and reward people for making resources available.

@alcinnz @rysiek @Shamar

@rysiek @Shamar @alcinnz

Briair also works without an Internet connection, so I think it can send messages over Bluetooth or local adhoc WiFi. Which I find really interesting. It's useful if the gov turns off the Internet!

@ebel @Shamar @alcinnz exactly. And it's not just about messages, it's also about content like blogs.

For me this might be a game changer.

@rysiek @Shamar @alcinnz I just wish I knew/had met anyone else who uses it... :(

The next step up from p2p apps/sites is meshnets, esp using mobile devices. The hardware is there, why aren't we using it!

@ebel @rysiek @Shamar I know exactly how you feel. It's the same for me. ๐Ÿ˜ž

@alcinnz @rysiek @Shamar
I know Briar wants to only work with people you meet in person, but I wonder if we could screenshot/share codes and try it out? ๐Ÿค”

@ebel @alcinnz @Shamar well, Briar also supports people introducing their contacts to each other, which is nice.

The codes are verified via Bluetooth or local connection, so we would have to set up a VPN to cheat it.

@ebel @alcinnz @Shamar any hacker conferences/camps you plan to visit this year?

@rysiek @ebel @alcinnz

Sadly I cannot move much... but I will look at these technologies.

As for Filecoin I had understood it is based on blockchain anyway...

@Shamar Yes, AFAIK #FileCoin is a blockchain, but that just means a distributed immutable database. I don't think it needs wasteful CPU/GPU mining, which is one of the big downsides

@ebel

Are you sure?

AFAIK #blockchain exactly means a specific group of algorithms/datastructures for distributed consensus based on wasteful CPU/GPU mining.

@Shamar No, I'm just kinda thinking out loud/guessing. I'd need to read the paper more.
Of course, #FileCoin isn't available, so it doesn't do anything yet

@ebel @alanz
I might look a bit boring about #CryptoCurrencies and #blockchain.

I studied #BitCoin infrastructure years ago and I did find the trick nice, but the whole stuff useless.

Finally I understood: it's just an expensive #ponzi scheme.

I cannot really understand how self respecting developers can try to sell it. It's broken by design, as it cannot survive in the long run.
So while #bitcoin had the mitigating circumstance to be a first experiment, everything that come later is a scam.

@Shamar

For my part I am more interested in the edge computing, distributed apps side of things.

@ebel

@Shamar @ebel @rysiek @pettter @HerraBRE @bjoern @galaxis @alanz

I have used and like everything @rysiek mentioned, but I've got to add IPFS and Dat to the list.

And on the periphery of that the Service Workers W3C standard should help them gain more traction.

@alcinnz @Shamar
#IPFS is pretty cool. Theyv'e done a lot of things to make it easy to use (browser extension, HTTP access). But I just can't get over the lack of crypto. It seems too much like a global caching system for websites...

@ebel @Shamar That's pretty much what it is.

At the same time there is crypto in IPNS, and you can always layer crypto ontop of IPFS if you want some sort of access control.

@rysiek @pettter @herrabre @bjoern

> I also feel that (quoting Eben Moglen, I think),
> the server must die to save the web.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> As long as we have servers, we will have centralization.

Why didn't Opera Unite[0] cause more of a commotion than it did? It never even made its way into the mainline browser before it petered out. They were really on to something there, even if solutions like it and PageKite insert a mediator to bridge the fact that the end-to-end internet is still dead.

I really wish more ISPs did Teredo well, until they have native IPv6.

[0] https://www.operasoftware.com/press/releases/general/opera-unite-reinvents-the-web
Correction: Sounds like Unite was in mainline Opera 11 and 12 but deprecated in 12?

http://help.opera.com/Windows/12.10/en/unite.html

> From Opera 12, Opera Unite has been removed by default for new users and will eventually be phased out.
Another correction: Unite was originally in a special Opera 10, but apparently it was in mainline Opera 10.10.

https://tech.slashdot.org/story/09/11/23/1940206/opera-1010-released-includes-new-unite-tech

@clacke @pettter @HerraBRE @bjoern I have not heard about Opera Unite before. Interesting (but closed source, no?)

@rysiek @clacke @pettter @bjoern Opera Unite was ahead of its time!

Yes, it was mostly closed. I think they did some lip service open stuff on the side to try and tempt people to develop for it, but not enough for it to ever really take off.

I think this also predated node.js, so people hadn't yet accepted the idea that you could write useful server-type software in JS.

With hind-sight, I should have written PageKite in JS and made it available both standalone and as a browser plugin.

@herrabre @pettter @rysiek @bjoern

I don't know much about Unite. I just remember that it was announced, and I thought it sounded interesting but didn't dive in because it was proprietary, and the next thing I heard, it died.

So the Unite widgets were written in Javascript? That's interesting.

@clacke @pettter @rysiek @bjoern I think so, but don't take my word for it.

Even if they weren't - today people would definitely use JS for this sort of thing and nobody would bat an eyelid. That was not the case then.

@rysiek @pettter @HerraBRE @bjoern In the context of Mastodon I think we're stuck with client/server. Which is ok - that's a proven model to reduce complexity in communications systems, and it's something that works now. Personally, I don't believe in P2P for the broad masses. For example, people have many devices, but want to have one identity. Ask the authors of any encrypted messenger how hard a problem that is. Never mind storage and compute requirements, especially for broadcast media.

@rysiek @pettter @HerraBRE @bjoern (And people may carry small supercomuters, but they don't carry small power plants. If they were to fully use the compute capacity of their smart devices on the go, they would run down their batteries within hours.)

@rysiek @pettter @HerraBRE @bjoern

Peer-to-peer is just marketing-speak for "everyone runs a server."

@rysiek @pettter @HerraBRE If we are able to remove the server component completely then we are talking about something complete different, where I would be more optimistic as well. Because then "running your social network" is really like "running your LibreOffice". But as long as the server maintenance is part of the equation, I doubt it.

@bjoern @pettter @HerraBRE depends on how complicated the "server maintenance" bit is.

How complicated is it, really, for a single-user instance? Can it be made simpler? It seems it could be made simpler if we create a piece of software that is explicitly single-user, doesn't need a database better than sqlite, etc, etc. We can make certain assumptions about single-user instances we can't about multi-user ones, and that can simplify stuff a lot!

And soon it stops being "server management".

@rysiek @herrabre @bjoern Are there user pings in your ideal network? Can they be muted? How? Is there a grouping of users to block? Can I delegate that somehow? Can I keep my social presence even while under attack from a harassment campaign or even just a regular slashdotting?

Do I need to know regular expressions for any of this to be feasible?

@pettter @HerraBRE @bjoern people are already blocking users in their feeds. On a single-user instance this would be the same thing as a instance-block.

Can most Mastodon instances survive slashdotting? I don't think so. And being on a single-user instance makes it less likely your instance gets slashdotted. This point is moot.

No, you do not need to know regexes. Don't like the user, block or mute them, just like you would have in your regular feed.

@rysiek @herrabre @bjoern >ย  On a single-user instance this would be the same thing as a instance-block.

Sometimes you want an instance-block rather than a single-user block. This pushes additional work and effort onto the single person being harassed.

> No, you do not need to know regexes. Don't like the user, block or mute them, just like you would have in your regular feed.

This assumes that malignant users are persistent and not presenting as entirely new entities for harassment purposes.

In a federated system this is mitigated by temporarily muting all free-signup instances.

@rysiek @pettter @HerraBRE @bjoern

I really don't think most instances could survive a slash-dotting until at least mastodon implements some sort of partitioning schema within their model.

You really can't shove everything in 1 datafile and expect everything to run awesomely smoothly (unless you have data retention processes put in place).

As the volume changes and size of indexes grow, storage requirements change. The time it takes to R/W really begins to take a shitter.

@bjรถrn How would you move your identity if you _are_ the identity? :]

(and perhaps more interesting for most people: how would you use a pseudonym in a network where you _are_ the node/instance?)

@pettter Because you're being an asshole, again.

I answer your question, you ignore the answer and ask it again.

I say Mailpile is a web server, you ignore that and say that because it's an e-mail client it's not relevant. Fuck that shit.

I get that you think servers are hard and clients are easy. We disagree, and you're obnoxious about it.

I'm ignoring you now.

@HerraBRE I'm pretty sure being an asshole has a slightly higher threshold than possible-misunderstanding-regarding-an-answer-in-a-quick-discussion-and-asking-it-anew.

It's interesting what hasty pseudo-realtime text communication does to people!

@mmn This happens a lot between Petter and myself. I'm getting a bit tired of it, so maybe my fuse is shorter than it should be.

Note that I indicated to him earlier in the thread that I felt his communication was hostile, which he ignored and then escalated.

I have plenty of debates with others that don't devolve like this.

If it keeps up I'll just block or mute him, which would be a shame because I think he's generally a good guy.

@HerraBRE Out of all my experience with @pettter I've felt that whatever questions he's had have been for the progression of the discussion and not in any way to smite anyone. :]
@HerraBRE @pettter see here's the fun part. We'll both report you for being an asshole with a superiority complex because you act like this towards everyone. Hopefully your instance admin will ban your account. Then you'll have more time to think about your behavior and how difficult single user instances are to maintain for a non-technical user.

@feld @pettter Dunno if this was directed at me or Petter, but I'm not reporting anyone for anything.

Please don't jump in and try to inflame things even further.

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 The "Federation model" is _not_ "idealistic admins".

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

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