@irenes @vathpela @dalias @natty @malwaretech Fair point indeed. Founders generally starting with ill-intent doesn't lend itself to them wanting to actually put their actions where their words are or making any correct logical inferences that would compromise their actual intent.

Regarding general meetings & "webcams" or really, synchronous communication, I'm also very much not convinced that this is the preferable model. #AsynchronousCommunication tends to be more accessible & inclusive.

@tiago The problem, inherently is that thin-clients are always a mistake and server-centrism is a horrible design focus.

Smart clients and featureful #UserAgent programs are what should be the norm, then all that is known by your client can be worked with however you want.

No more shit like favorites disappearing because the instance that originally emitted them has since gone offline.

The full logical extent of this idea is #P2P & #AsynchronousCommunication but many seem not ready for that.

@eater @noracodes There's also #AsynchronousCommunication like #NNCP, which makes no assumption of adequacy & fitness of infrastructure (such assumptions are often wrong).

But also some #meshnet projects like #Gnunet do actually (optionally) handle the lower layers of the networking stack (short of physical itself).

So many of those blogs about #GPG being bad make this weird mistake of going "but there are no good reasons to encrypt messages or files as standalone units, use encrypted chat/synchronous transfer like magic-wormhole", completely ignoring that #AsynchronousCommunication is a use-case that absolutely should be supported.

So that leaves you with #age or #NNCP (among others), though many of those articles fail to mention either of them.

Why do people assume reliable low-latency connectivity?

@heapwolf @toolbear @brewsterkahle Without using offgrid networking (which tends to mean #AsynchronousCommunication or otherwise more expensive setting up parallel infrastructure), surveillance is a constant risk.

And while having a few hops of indirection is a minimal measure, if nothing is done about timing, packet sizes, etc, then sufficient analysis will still allow a global observer (such capacity is commercially available) to deanonymize participants.

@ellenor2000 Aye, and yes.

A lot of good ideas there, and unlike *many* other protocols and standards, it lends itself exceedingly well to #AsynchronousCommunication, as it was in fact a major design consideration.

It makes its use away from the #clearnet, or indeed away from any network or peer outside of occasional synchronization, a definite option.

@yawnbox > made by white Americans for privileged users not behind Orwellian government firewalls/censorship
Right, link obfuscation is unmentioned and it doesn't seem to lend itself much at all to #AsynchronousCommunication.

@moof @efi @darkphoenix Perhaps not the same reasons as me, but having to get #clearnet hosting has some pretty nasty deanonymization / #privacy risks and some considerable costs.

The assumption of constant end-to-end connectivity also greatly complicates multi-network uses such as say... hosting on #Tor, #I2P and #Freenet (for example) at the same time. Or hosting primarily on I2P but intending to interact with clearnet instances.

In general, #AsynchronousCommunication sadly was ignored.

@mike805 @jeffcliff @brewsterkahle Additionally, for such hostile environments high-latency store & forward networks are better suited than either #Tor or #I2P.

Unfortunately #AsynchronousCommunication generally gets shafted in people's prioritization & considerations, so there's much less work done on those at the moment.

#DTN #StoreAndForward #DelayTolerance #DelayTolerantNetworking

@aprilfollies @pluralistic If you're actually interested in #sneakernet and #AsynchronousCommunication, you might find #NNCP interesting.

It's a renewed #UUCP essentially, with modern encryption & first-class support for portable storage as a transport (https://nncp.mirrors.quux.org/Comparison.html).

@tommorris So much of this is on us for creating this absurd trove of software that depends on low-latency continuous network connectivity.

#AsynchronousCommunication should be a primary concern in software design for exactly this sort of reason.

If someone could just stick a store-and-forward node on a bus or something it would be much harder for corposcum to successfully create such anticompetitive ISPs as bypassing them would be trivial.

@david_megginson @pooserville A general keyword pertaining to this would be #AsynchronousCommunication.

Most systems implementing/supporting it are de-facto P2P, but that isn't a hard requirement (it is technically an orthogonal property, it has similar but not exactly identical implications to "delay-tolerant").

@lucian, if you’re able to make it work I’d love to hear more about your process and the outcomes. #asynchronouscommunication particularly in an #agile framework is a key interest of mine. Would you be willing to share artifacts from retros ?

@pvonhellermannn @gerrymcgovern Much of the issue with the absurd reliability requirements datacenters have to deal with are due to the current and bizarre trend of disregarding #AsynchronousCommunication as the primary mode of interaction between programs, people and businesses.

Such communication is much more tolerant to disruption and delays, and can be explicitly strengthened in those aspects.

@navi @bartavi #Email has a much better defined retry behavior in SMTP.

(Protocols dependent on successful low-latency TCP connections essentially don't qualify as supporting #AsynchronousCommunication, https://www.complete.org/asynchronous-communication/, email as commonly used does as noted there)

It is also simply not dependent on #SMTP in the first place, you can use #UUCP, #NNCP, #fidonet or a thumb drive (or floppy) with a spool just as well for it.

#ActivityPub as defined by the standard lacks that flexibility.

@navi Except more brittle and supporting solely synchronous networking with no alternative #AsynchronousCommunication delivery methods.

@dalias @astraleureka @xarvos @faoluin @ariadne It's funny that newer protocols tend to deal with asymmetric/diverse link methods (phone, sneakernet, internet, etc), some necessitating first-class support for #AsynchronousCommunication, so badly.

#Usenet, #UUCP and #Fidonet (#email is an outlier that can be carried by all of those and #SMTP too) all dealt with that much better. Of recent projects, only #NNCP and #SSB (and a few more niche ones) appear to have given any real thought to that.

@troglodyt @tomo Amusingly, I've been thinking that going back to #AsynchronousCommunication over phonelines would actually be viable in this scenario.

The content of phone calls is protected much more tightly than the metadata, after all.

@shoq The answer to your question is no (https://support.torproject.org/about/attacks-on-onion-routing/).

Neither will #I2P on its own suffice if they're willing to do enough collateral damage in their search.

#Loopix implementations (which address padding & timing to a greater degree) also wouldn't suffice for the same reasons.

Out-of-band #AsynchronousCommunication (perhaps mediated through #NNCP) and rebroadcasted through those networks would however help with spreading messages.

#Tor

@animeirl @maija That's part of it, but given #AsynchronousCommunication is a thing, it can trivially be extended to what I suggest.