#AsynchronousCommunication

Monospace MentorZulip 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% <a href="https://floss.social/tags/OpenSource" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#OpenSource</a>!Check it out at <a href="https://zulip.com/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://zulip.com/</a>!<a href="https://floss.social/tags/Teamwork" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Teamwork</a> <a href="https://floss.social/tags/Chat" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Chat</a> <a href="https://floss.social/tags/Collaboration" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Collaboration</a> <a href="https://floss.social/tags/AsynchronousCommunication" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#AsynchronousCommunication</a> <a href="https://floss.social/tags/RemoteWork" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RemoteWork</a> <a href="https://floss.social/tags/RemoteCulture" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RemoteCulture</a>

LisPi<a class="u-url mention" href="https://tech.lgbt/@wakame" rel="nofollow noopener noreferrer" target="_blank">@wakame</a> <a class="u-url mention" href="https://mastodon.me.uk/@gilest" rel="nofollow noopener noreferrer" target="_blank">@gilest</a> 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 <a class="hashtag" href="https://udongein.xyz/tag/asynchronouscommunication" rel="nofollow noopener noreferrer" target="_blank">#AsynchronousCommunication</a>). (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).

LisPi<a class="u-url mention" href="https://hachyderm.io/@dalias" rel="nofollow noopener noreferrer" target="_blank">@dalias</a> <a class="u-url mention" href="https://mstdn.social/@_L1vY_" rel="nofollow noopener noreferrer" target="_blank">@_L1vY_</a> <a class="u-url mention" href="https://mastodon.laurenweinstein.org/@lauren" rel="nofollow noopener noreferrer" target="_blank">@lauren</a> 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 <a class="hashtag" href="https://udongein.xyz/tag/asynchronouscommunication" rel="nofollow noopener noreferrer" target="_blank">#AsynchronousCommunication</a>... but a lot of other options, some newer and some a lot older, do have very good support for those things.

LisPi<a class="u-url mention" href="https://tech.lgbt/@normjess" rel="nofollow noopener noreferrer" target="_blank">@normjess</a> <a class="u-url mention" href="https://tech.lgbt/@david" rel="nofollow noopener noreferrer" target="_blank">@david</a> I'd say ultimately anything that is server-centric is priming itself for abuse. Anything that makes no provisions for <a class="hashtag" href="https://udongein.xyz/tag/p2p" rel="nofollow noopener noreferrer" target="_blank">#P2P</a> and/or <a class="hashtag" href="https://udongein.xyz/tag/asynchronouscommunication" rel="nofollow noopener noreferrer" target="_blank">#AsynchronousCommunication</a> (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.

LisPi<a class="u-url mention" href="https://bananachips.club/@qwazix" rel="nofollow noopener noreferrer" target="_blank">@qwazix</a> <a class="u-url mention" href="https://retro.social/@ajroach42" rel="nofollow noopener noreferrer" target="_blank">@ajroach42</a> It is thankfully achievable to have something similar with <a href="https://www.torproject.org/" rel="nofollow noopener noreferrer" target="_blank">Tor</a>/<a href="https://geti2p.net/en/" rel="nofollow noopener noreferrer" target="_blank">I2P</a>/<a href="https://veilid.com/" rel="nofollow noopener noreferrer" target="_blank">Veilid</a>, 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 <a href="https://mastodon.top/@lispi314/111253066257920146" rel="nofollow noopener noreferrer" target="_blank">low-latency networking problem</a> and fail to provide resilient <a class="hashtag" href="https://udongein.xyz/tag/asynchronouscommunication" rel="nofollow noopener noreferrer" target="_blank">#AsynchronousCommunication</a>.

LisPiUnfortunate observations as far as <a class="hashtag" href="https://udongein.xyz/tag/asynchronouscommunication" rel="nofollow noopener noreferrer" target="_blank">#AsynchronousCommunication</a> facilitation goes. There appears to be no user-friendly way to use <a class="hashtag" href="https://udongein.xyz/tag/nncp" rel="nofollow noopener noreferrer" target="_blank">#NNCP</a> on <a class="hashtag" href="https://udongein.xyz/tag/android" rel="nofollow noopener noreferrer" target="_blank">#Android</a>. 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).

LisPiI have complicated feelings regarding <a href="https://mastodon.top/tags/Usenet" class="mention hashtag" rel="tag">#Usenet</a> and <a href="https://mastodon.top/tags/NNTP" class="mention hashtag" rel="tag">#NNTP</a> due to some server-centric aspects.Granted due to message <a href="https://mastodon.top/tags/gossip" class="mention hashtag" rel="tag">#gossip</a> 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 <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> 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.

LisPi<a href="https://mastodon.slightlycyberpunk.com/@admin" class="u-url mention">@admin</a> <a href="https://silicorn.social/@jess" class="u-url mention">@jess</a> 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 <a href="https://mastodon.top/tags/P2P" class="mention hashtag" rel="tag">#P2P</a> programs that focus far more the <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> aspect, because nodes will *usually* be isolated.

LisPi<a href="https://mastodon.sdf.org/@screwtape" class="u-url mention">@screwtape</a> <a href="https://mastodon.top/@ellenor2000" class="u-url mention">@ellenor2000</a> Not necessarily per se, it's really only once one has both <a href="https://mastodon.top/tags/P2P" class="mention hashtag" rel="tag">#P2P</a> and <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> that things get very interesting.Unreliable uptime also isn't quite the asynchronicity I refer to (<a href="https://www.complete.org/asynchronous-communication/" target="_blank" rel="nofollow noopener noreferrer" translate="no">https://www.complete.org/asynchronous-communication/</a>). Rather, I'm referring to a system developed with no expectation of ever having a low-latency route to the end destination at all.<a href="https://mastodon.top/tags/Usenet" class="mention hashtag" rel="tag">#Usenet</a> is your classical example. Use <a href="https://mastodon.top/tags/UUCP" class="mention hashtag" rel="tag">#UUCP</a> (<a href="https://mastodon.top/tags/NNCP" class="mention hashtag" rel="tag">#NNCP</a> now) or mailed floppies to update your spool. It's supported.

LisPiI 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 <a href="https://mastodon.top/tags/P2P" class="mention hashtag" rel="tag">#P2P</a> systems and <a href="https://mastodon.top/tags/federated" class="mention hashtag" rel="tag">#federated</a> systems just has that flaw jump to their eyes when the state of <a href="https://mastodon.top/tags/ActivityPub" class="mention hashtag" rel="tag">#ActivityPub</a> implementations is seen, and in general how *no* importance is given to <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> communication in the spec and nearly as little to P2P use.Basically, what did you expect? Of course it'll devolve into petty fiefdoms.

LisPi<a href="https://mstdn.plus/@gcvsa" class="u-url mention">@gcvsa</a> <a href="https://mastodon.top/tags/Gnus" class="mention hashtag" rel="tag">#Gnus</a> is still pretty good (and the <a href="https://mastodon.top/tags/Emacs" class="mention hashtag" rel="tag">#Emacs</a> editor it comes with).I do agree, of course.<a href="https://mastodon.top/tags/Usenet" class="mention hashtag" rel="tag">#Usenet</a> also didn't have such tight coupling with the <a href="https://mastodon.top/tags/clearnet" class="mention hashtag" rel="tag">#clearnet</a> either, or indeed much in the way of assumptions for low-latency networking, it has first-class support for <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a>.

LisPi<a href="https://lemmy.ml/u/mlfh" class="u-url mention">@mlfh</a> <a href="https://lemmy.ca/u/cecilkorik" class="u-url mention">@cecilkorik</a> Thankfully not everyone has been ignoring the <a href="https://mastodon.top/tags/clearnet" class="mention hashtag" rel="tag">#clearnet</a> unreliability and <a href="https://mastodon.top/tags/infrastructure" class="mention hashtag" rel="tag">#infrastructure</a> requirements, so some <a href="https://mastodon.top/tags/P2P" class="mention hashtag" rel="tag">#P2P</a> program with <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> (<a href="https://www.complete.org/asynchronous-communication/" target="_blank" rel="nofollow noopener noreferrer" translate="no">https://www.complete.org/asynchronous-communication/</a>) do exist, like <a href="https://mastodon.top/tags/NNCP" class="mention hashtag" rel="tag">#NNCP</a>, <a href="https://mastodon.top/tags/SSB" class="mention hashtag" rel="tag">#SSB</a> and <a href="https://mastodon.top/tags/Briar" class="mention hashtag" rel="tag">#Briar</a>.They can all use the <a href="https://mastodon.top/tags/internet" class="mention hashtag" rel="tag">#internet</a> 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.

LisPi<a href="https://lemmy.world/u/ad_on_is" class="u-url mention">@ad_on_is</a> The truth is that the <a href="https://mastodon.top/tags/internet" class="mention hashtag" rel="tag">#internet</a> 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 <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> (which <a href="https://mastodon.top/tags/Usenet" class="mention hashtag" rel="tag">#Usenet</a> demonstrated) is an essential property. <a href="https://mastodon.top/tags/Anonymization" class="mention hashtag" rel="tag">#Anonymization</a>, <a href="https://mastodon.top/tags/P2P" class="mention hashtag" rel="tag">#P2P</a> routing & key-addressing are also minimum requirements to hinder trivial censorship. <a href="https://mastodon.top/tags/Mixnet" class="mention hashtag" rel="tag">#Mixnet</a> operation is even better.

LisPiSupport for <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> (<a href="https://www.complete.org/asynchronous-communication/" target="_blank" rel="nofollow noopener noreferrer" translate="no">https://www.complete.org/asynchronous-communication/</a>) would represent the least of due care for these circumstances.You cannot assume conditions in which <a href="https://mastodon.top/tags/TCP" class="mention hashtag" rel="tag">#TCP</a> 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 <a href="https://mastodon.top/tags/privilege" class="mention hashtag" rel="tag">#privilege</a>.The applicability of any program with such assumptions is inherently tightly constrained.<a href="https://mastodon.top/tags/Networking" class="mention hashtag" rel="tag">#Networking</a> <a href="https://mastodon.top/tags/Network" class="mention hashtag" rel="tag">#Network</a> <a href="https://mastodon.top/tags/Software" class="mention hashtag" rel="tag">#Software</a> <a href="https://mastodon.top/tags/Programming" class="mention hashtag" rel="tag">#Programming</a>

LisPi<a href="https://mastodon.art/@misnina" class="u-url mention">@misnina</a> 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.<a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> and <a href="https://mastodon.top/tags/offline" class="mention hashtag" rel="tag">#offline</a> capacity are essential to support.

LisPi<a href="https://oldbytes.space/@millihertz" class="u-url mention">@millihertz</a> Safely implementing <a href="https://mastodon.top/tags/cryptography" class="mention hashtag" rel="tag">#cryptography</a> 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 / <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> 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.

LisPi<a href="https://impeccable.social/users/billstclair" class="u-url mention">@billstclair</a> <a href="https://mastodon.social/@jesseplusplus" class="u-url mention">@jesseplusplus</a> 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 <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> capacities & transport agnosticism of our prior solutions as essential to preserve.

LisPi<a href="https://plasmatrap.com/@privateger" class="u-url mention">@privateger</a> <a href="https://social.naln1.ca/users/Elizafox" class="u-url mention">@Elizafox</a> Both <a href="https://mastodon.top/tags/I2P" class="mention hashtag" rel="tag">#I2P</a> and <a href="https://mastodon.top/tags/Veilid" class="mention hashtag" rel="tag">#Veilid</a> 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 <a href="https://mastodon.top/tags/NNCP" class="mention hashtag" rel="tag">#NNCP</a>, <a href="https://mastodon.top/tags/Briar" class="mention hashtag" rel="tag">#Briar</a> and <a href="https://mastodon.top/tags/SSB" class="mention hashtag" rel="tag">#SSB</a> (<a href="https://mastodon.top/tags/SecureScuttleButt" class="mention hashtag" rel="tag">#SecureScuttleButt</a>) will all still be operational without it, by <a href="https://mastodon.top/tags/sneakernet" class="mention hashtag" rel="tag">#sneakernet</a> and <a href="https://mastodon.top/tags/snailmail" class="mention hashtag" rel="tag">#snailmail</a> if nothing else.<a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a>

LisPi<a href="https://social.naln1.ca/users/Elizafox" class="u-url mention">@Elizafox</a> Rather, something that can easily be transported over as many given transports as possible and doesn't make any assumptions about timing (and so doesn't expect a synchronous or real-time connection) is a better idea.When the <a href="https://mastodon.top/tags/Internet" class="mention hashtag" rel="tag">#Internet</a> is available? Then let's carry over the internet, but when it's not we should have <a href="https://mastodon.top/tags/sneakernet" class="mention hashtag" rel="tag">#sneakernet</a>, we should have <a href="https://mastodon.top/tags/FSO" class="mention hashtag" rel="tag">#FSO</a>, and we still have the telephone lines (yes, even now you can still setup modem stuff).<a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a>

LisPi<a href="https://social.naln1.ca/users/Elizafox" class="u-url mention">@Elizafox</a> <a href="https://mastodon.top/tags/GNUnet" class="mention hashtag" rel="tag">#GNUnet</a> (for all its many faults) does support the entire network stack down the lowest layers, all you need at that point is a signalling substrate (<a href="https://mastodon.top/tags/DIY" class="mention hashtag" rel="tag">#DIY</a> <a href="https://mastodon.top/tags/FSO" class="mention hashtag" rel="tag">#FSO</a> like <a href="https://mastodon.top/tags/RONJA" class="mention hashtag" rel="tag">#RONJA</a> is cool).It's not the only <a href="https://mastodon.top/tags/meshnet" class="mention hashtag" rel="tag">#meshnet</a> we've got.But I think persistent connectivity instead of <a href="https://mastodon.top/tags/AsynchronousCommunication" class="mention hashtag" rel="tag">#AsynchronousCommunication</a> would be the wrong thing to focus on.Setting up our own infrastructure to compete with that of the government and corporations isn't the right approach (or the main one, anyway).

Recherches récentes

Options de recherche

Administré par :

Statistiques du serveur :

#AsynchronousCommunication