witches.town / SaaS critique Show more
witches.town / SaaS critique Show more
witches.town / SaaS critique Show more
@pettter @bjoern You sound sarcastic and hostile, am I misreading?
#Mailpile 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.
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.
@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.
@rysiek @pettter @HerraBRE @bjoern This sounds like "Counter-Anti-Dsintermediation".
http://wiki.p2pfoundation.net/Counter-Anti-Disintermediation
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
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).
@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 @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.
@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.
@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.
@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. ;)
@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 @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.
@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 @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.
@Shamar
It sounds like you are describing a CRDT based system. And / or secure scuttlebutt.
https://en.m.wikipedia.org/wiki/Conflict-free_replicated_data_type
https://www.scuttlebutt.nz/
See also Tyler McMullen of Fastly talk about this stuff: https://m.youtube.com/watch?v=9KDPNj8oy3k
@bjoern @galaxis @HerraBRE @rysiek @pettter @ebel