<p>The alt.os.linux.slackware FAQs [1] are one of the most comprehensive resources to get started with Slackware.<br> <br>[1] <a href="https://www.therockgarden.ca/aolsfaq.txt" rel="nofollow" class="ellipsis" title="www.therockgarden.ca/aolsfaq.txt"><span class="invisible">https://</span><span class="ellipsis">www.therockgarden.ca/aolsfaq.t</span><span class="invisible">xt</span></a></p><p><a href="/tags/slackware/" rel="tag">#slackware</a> <a href="/tags/usenet/" rel="tag">#usenet</a></p>
<p>Slack's owner has fully revealed himself as a fascist bootlicker and MAGAt. Discord is selling your stuff to train AI. ChatGTP is keeping all the stuff they swear they're deleting. I've got groups that need to work on projects from spread-out locations, but I've deleted my account at virtually all group platforms like these. What can we possibly use these days?</p><p>Same as I always have. <a href="/tags/irc/" rel="tag">#IRC</a>. <a href="/tags/usenet/" rel="tag">#Usenet</a>. <a href="/tags/bittorrent/" rel="tag">#BitTorrent</a>.</p>
Scaling: ActivityPub over NNTP?
<p>Here’s an interesting thought experiment. </p><p>Way back in the 1980s and 90s, Usenet was a sorta-federated discussion forum (using the NNTP protocol) that was very popular. It still exists and <a href="https://en.wikipedia.org/wiki/Usenet#Usenet_traffic_changes" rel="nofollow">is distributing 400 million messages each day</a> (mostly spam and trash as far as I can tell). Hard numbers are difficult to come by but it seems like Usenet is capable of significantly higher throughput. Why is that? </p><p>The big thing holding ActivityPub back is the fan-out. You know the story - someone with 50,000 followers causes their instance to send up to 50,000 HTTP POSTs every time they click the little spinny star or reply to something. </p><p>It’s basically a hub-and-spoke network topology. Except everyone takes turns being the hub, ideally, but not much in practice. And in this topology, the hubs are where the strain and bottlenecks are. </p><p>Back in the 1980s they had computers literally 1000 times slower than ours and network links to match. So how did they do this? With a peer to peer network topology! When a new post is made, they don’t send it to everyone they just send it to a handful of other servers. Those servers in turn forward the post on to a handful of other peers, and so on, until the whole network receives the post. No individual server is a single point of failure and none has to bear the full brunt of orchestrating it all. </p><p>Let’s do a picture. A creates a post and sends it to B and D. </p><p>A ─ B ─ C \ / ─ D ─ </p><p>B sends it on to C. </p><p>Meanwhile D sends it on the C also but C already has it so does nothing more. IRL this would be a much larger mesh. Who peers with who can be a mixture of manual selection and random spiciness. </p><p>Posts can arrive out of order so each server would need to wait until the dependencies between posts are resolved before making them available to clients. That’s a bit tricky. </p><p>In the ActivityPub-over-NNTP idea, each NNTP post would be a thin wrapper around a data structure containing the HTTP headers (with signature and digest) and JSON that a normal HTTP POSTed Activity would have. Servers would use NNTP to distribute the activities and upon receiving one they’d POST it to their own /inbox to run the usual ActivityPub processing that their AP instance does. </p><p>{ "headers": { "Signature": "...", "Digest": "...", "Date": "..." }, "activity": { ... normal ActivityPub JSON ... } } </p><p>In this way there is no need to rewrite ActivityPub semantics as only the transport layer changes. Our existing inbox logic remains intact. </p><p>NNTP comes with a lot of historical baggage so we’d probably need to evolve the protocol a bit. Maybe use HTTP requests (even http2 streams?) instead of <a href="https://datatracker.ietf.org/doc/html/rfc3977" rel="nofollow">the original line-oriented text protocol using raw TCP sockets</a>. But you get the idea. </p><p>Thoughts?</p>
<small class="notice" x-post-type-data="None">
Takahe has limited support for this type: <a href="https://piefed.social/c/technical-discussion/p/1939768/scaling-activitypub-over-nntp">See Original Page</a>
</small>
Back to the future - Interacting with threadiverse communities through Usenet / NNTP
<p>A few months ago I threw this question out into the void - “what if you could access the fediverse through your Usenet reader??” and got almost no response. Still, the idea had lodged in my brain and wouldn’t go away so this weekend I caved in and built the thing. Hat tip to the author of the excellent <a href="https://pypi.org/project/nntpserver/" rel="nofollow">nntpserver package</a> that did all the hard stuff. </p><p>I look forward to seeing someone’s screenshots of fediverse posts on a Commodore 64, some day. </p><p>This will be released as a part of PieFed 1.7, coming soon.</p>
<small class="notice" x-post-type-data="None">
Takahe has limited support for this type: <a href="https://piefed.social/c/piefed_meta/p/1904499/back-to-the-future-interacting-with-threadiverse-communities-through-usenet-nntp">See Original Page</a>
</small>
Back to the future - Interacting with threadiverse communities through Usenet / NNTP
<p>A few months ago I threw this question out into the void - “what if you could access the fediverse through your Usenet reader??” and got almost no response. Still, the idea had lodged in my brain and wouldn’t go away so this weekend I caved in and built the thing. Hat tip to the author of the excellent <a href="https://pypi.org/project/nntpserver/" rel="nofollow">nntpserver package</a> that did all the hard stuff. </p><p>I look forward to seeing someone’s screenshots of fediverse posts on a Commodore 64, some day. </p><p>This will be released as a part of PieFed 1.7, coming soon.</p>
<small class="notice" x-post-type-data="None">
Takahe has limited support for this type: <a href="https://piefed.social/c/retrocomputing/p/1950566/back-to-the-future-interacting-with-threadiverse-communities-through-usenet-nntp">See Original Page</a>
</small>