Lmst

Connected, yet apart! Curious about async communication? Click this blog to find out how it can work for you!

https://wpwax.com/asynchronous-communication/

#async #asynchronouscommunication #digitalcommunication #communicationtips #communicationtools #businesscommunication #communicationstrategy

Zulip is absolutely underrated as a chat platform for teams. Its automatic threading makes it so much easier to catch up on previous conversations than with Slack, Teams or Discord. In my opinion, Zulip is ideal for distributed teams who prefer to work and communicate asynchronously -- like my team, for example.

And it's 100% #OpenSource!

Check it out at https://zulip.com/!

#Teamwork #Chat #Collaboration #AsynchronousCommunication #RemoteWork #RemoteCulture

@wakame @gilest File transfer could be done with something like magic-wormhole, there really just needs to be a user-friendly UI (problem is that it's a synchronous-use program).

Something like NNCP + syncthing for uninteractive multiple-retry would also be an option (based #AsynchronousCommunication).

(Supporting Veilid would be useful for all of those, since it takes care of the TURN-style & relay shenanigans necessary for NAT traversal and other similar annoyances.)

The homepage/blog can just be content-addressed, but it'd need to be in the Freenet/dat way rather than IPFS: not just addressing the content but incorporating an encryption key so that various caches along the path that do not have the capability/link for the decrypted file can't decrypt it. (Yes, all of those support mutable/updatable documents.)

(I'm working off the notion private = restricted access, otherwise encrypting the document is completely unnecessary.)

Calendar/Email can also be handled with NNCP over Veilid. Calendar more specifically could also be handled with a mutation capability for an encrypted content-addressed document (which I suppose makes it more a reference to another document then but whatever, precedents already exist as I mentioned prior).

@dalias @_L1vY_ @lauren Correct, I do not foresee a way for them to really destroy NetNews and other highly-asynchronous communication networks.

"The (Use)net interprets censorship as damage and routes around it" line, essentially.

They would most likely manage to kill ActivityPub, because most of its implementations have little to no tolerance for disruption, have garbage support for transport-diverse networking and do not properly support #AsynchronousCommunication... but a lot of other options, some newer and some a lot older, do have very good support for those things.

@normjess @david I'd say ultimately anything that is server-centric is priming itself for abuse.

Anything that makes no provisions for #P2P and/or #AsynchronousCommunication (for basically anything that isn't expected to have a live real-time operator) also ensures it is unusable in adverse conditions such as those of emergency situations which affect infrastructure reliability.

Basically every time there is some big storm, snow, a power outtage or anything similar here, the mobile phones stop working within 8 hours at most if they didn't drop entirely from the very start. I would be surprised if no one has died as a consequence of this by now.

(In theory mobile infrastructure is supposed to have adequate backup power, though I'm not sure if there's anything legally binding about that here, but the Canadian telecom cartel isn't famous for its willingness to properly maintain its infrastructure.)

Meanwhile CB and HAM radios just keep on working like they always do. That's an example of resilient P2P technology.

Upgrade your online communication experience with HelpGent 2.0! Enjoy smoother interactions with advanced features. Time to take your conversations to the next level!

https://wpwax.com/helpgent-2-0-latest-edition/

#wordpress #plugins #wordpressplugins #communication #helpgent #asynchronous #communicationtools #asynchronouscommunication #videomessaging #audiomessaging #textmessaging #screenrecording #conversationalform #onlinesbusiness #latestedition #newfeatures #onlinecommunication #wpnews #businesscommunication

@qwazix @ajroach42 It is thankfully achievable to have something similar with Tor/I2P/Veilid, which I think also solve various issues of the clearnet notably the easily corruptible centralized authorities involved in cryptographic identity verification and attestation.

And also ISPs opposing certain types of traffic on their networks (like MTAs). They simply shouldn't have the insight into said traffic to make that decision in the first place. Their role is to be routing infrastructure, nothing more and so they shouldn't have any more knowledge than necessary to accomplish that task.

I actually have a full Linux computer as my router and no CGNAT (addresses are dynamically reused though, so dynamic DNS is necessary), so I can do the direct end-to-end connection stuff unlike many. It is quite nice.

Of course all of these don't solve the low-latency networking problem and fail to provide resilient #AsynchronousCommunication.

Unfortunate observations as far as #AsynchronousCommunication facilitation goes.

There appears to be no user-friendly way to use #NNCP on #Android.

This seems unfortunate, as mobile phones are essentially purpose-designed mobile nodes capable of bridging networks and being easily carried around.

I don't really have the kind of UI sense that NTs tend to like though, so I'm probably not the best person to rectify this lack (at least in any way conducive to the kind of mass adoption I think Asynchronous Communication should be seeing).

I have complicated feelings regarding #Usenet and #NNTP due to some server-centric aspects.

Granted due to message #gossip the death of any given instance isn't catastrophic and moving is largely unnoticeable, but it still puts some hurdles on usability in adverse conditions.

It still fulfills most of the #AsynchronousCommunication characteristics handily, but that's still a nagging thought, since /most/ instances demand fairly high-uptime to peer and don't allow such instability from peers.

@admin @jess In some cities there are such mesh networks.

Here that runs into issues about fucked up density and car-dependency in general, unfortunately.

It's still feasible, but any such mesh needs #P2P programs that focus far more the #AsynchronousCommunication aspect, because nodes will *usually* be isolated.

@screwtape @ellenor2000 Not necessarily per se, it's really only once one has both #P2P and #AsynchronousCommunication that things get very interesting.

Unreliable uptime also isn't quite the asynchronicity I refer to (https://www.complete.org/asynchronous-communication/). Rather, I'm referring to a system developed with no expectation of ever having a low-latency route to the end destination at all.

#Usenet is your classical example. Use #UUCP (#NNCP now) or mailed floppies to update your spool. It's supported.

I really can't help but look at this whole blocklist drama with some amusement tinged with exasperation.

Anyone who has done remotely any reading on #P2P systems and #federated systems just has that flaw jump to their eyes when the state of #ActivityPub implementations is seen, and in general how *no* importance is given to #AsynchronousCommunication communication in the spec and nearly as little to P2P use.

Basically, what did you expect? Of course it'll devolve into petty fiefdoms.

@gcvsa #Gnus is still pretty good (and the #Emacs editor it comes with).

I do agree, of course.

#Usenet also didn't have such tight coupling with the #clearnet either, or indeed much in the way of assumptions for low-latency networking, it has first-class support for #AsynchronousCommunication.

@mlfh @cecilkorik Thankfully not everyone has been ignoring the #clearnet unreliability and #infrastructure requirements, so some #P2P program with #AsynchronousCommunication (https://www.complete.org/asynchronous-communication/) do exist, like #NNCP, #SSB and #Briar.

They can all use the #internet as transports... but they don't need it. Messaging over encrypted mailed microSD cards is possible, or over bluetooth while in the same room.

We need more stuff like this, and I unfortunately don't have a good list.

@ad_on_is The truth is that the #internet should be considered useful as a WAN routing layer, but nothing should actually be using it directly as it is unreliable both because of malicious actors and because of gross neglect by many operators.

Support for #AsynchronousCommunication (which #Usenet demonstrated) is an essential property. #Anonymization, #P2P routing & key-addressing are also minimum requirements to hinder trivial censorship. #Mixnet operation is even better.

Support for #AsynchronousCommunication (https://www.complete.org/asynchronous-communication/) would represent the least of due care for these circumstances.

You cannot assume conditions in which #TCP will work. You cannot assume a bidirectional low-latency link can be established.

Not for anything intended for wide deployment without gating it off via infrastructural #privilege.

The applicability of any program with such assumptions is inherently tightly constrained.

#Networking #Network #Software #Programming

@misnina Governments around the world are demonstrating the internet can *willingly* be shut down at any moment because some elections or protest is going on somewhere.

Any pretense the internet is reliable depends on astounding privilege as far as infrastructure reliability goes, and willful ignorance of the ease with which various physical political actors can sabotage it, both "legitimately" and illegitimately.

#AsynchronousCommunication and #offline capacity are essential to support.

@millihertz Safely implementing #cryptography is a difficult matter.

There are some circumstances in which say, certain timing-based side-channels don't pose a risk (such as high-latency / #AsynchronousCommunication uses among the more obvious where there is no interaction by which to measure timings), but there's the general assumption the implementer has the background to know those.

And so if providing fixed & bounded runtime in your language is difficult, that becomes a bit troublesome.

@billstclair @jesseplusplus Quite, and so, seeing as we had this issue (data caps & the absurd billing involved in even minimal overcap traffic were essentially this), and the workarounds we had before, we should've considered that to always be a risk and conserving the #AsynchronousCommunication capacities & transport agnosticism of our prior solutions as essential to preserve.

@privateger @Elizafox Both #I2P and #Veilid unfortunately make the assumption that low-latency bidirectional connections can be attained.

Which is another way to say they assume the presence of the internet.

In ideal circumstances that's great... but such circumstances cannot be guaranteed.

Meanwhile for example #NNCP, #Briar and #SSB (#SecureScuttleButt) will all still be operational without it, by #sneakernet and #snailmail if nothing else.

#AsynchronousCommunication

#AsynchronousCommunication

Client Info