#COSCUP 2026(台北、8月8–9日)Fediverse & Social WebトラックのCFPが始まりました!#ActivityPub、#フェディバース、オープンなソーシャルウェブに関わる方のご応募をお待ちしています。締め切りは5月9日、参加費は無料です。
👉 https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp-ja
#fediverse #SocialWeb #fedidev
RE: https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp-ja
#COSCUP 2026(타이베이, 8월 8–9일) Fediverse & Social Web 트랙 발표자 모집이 시작되었습니다! #ActivityPub, #연합우주, 오픈 소셜 웹 관련 주제라면 무엇이든 환영합니다. 마감은 5월 9일이고, COSCUP 참가는 무료입니다.
👉 https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp-ko
RE: https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp-ko
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8–9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
👉 https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp
(Boosts appreciated!)
RE: https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp
COSCUP 2026 フェディバース & ソーシャルウェブ トラック:発表者募集
https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp-ja
COSCUP 2026 연합우주 & 소셜 웹 트랙: 발표자 모집
https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp-ko
Fediverse & Social Web track at COSCUP 2026: call for participation
https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp
Scaling: ActivityPub over NNTP?
Here’s an interesting thought experiment.
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 is distributing 400 million messages each day (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?
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.
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.
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.
Let’s do a picture. A creates a post and sends it to B and D.
A ─ B ─ C
\ /
─ D ─
B sends it on to C.
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.
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.
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.
{
"headers": {
"Signature": "...",
"Digest": "...",
"Date": "..."
},
"activity": { ... normal ActivityPub JSON ... }
}
In this way there is no need to rewrite ActivityPub semantics as only the transport layer changes. Our existing inbox logic remains intact.
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 the original line-oriented text protocol using raw TCP sockets. But you get the idea.
Thoughts?
Yes, #HolosSocial is far from perfect, but everything is being done to improve the UX. I still believe in this project because it offers a lot of perspectives, and bad behavior can be fixed.
Thank you to all the people trusting this project. Even if it fails, I am pretty sure it will help push #ActivityPub further.
Ich bin zu dumm für ActivityPub.
#ActivityPub
Stell dir vor: Du ziehst um, nimmst deine komplette Follower-Liste mit und dein neuer Server läuft auf dem Raspberry Pi deines Nachbarn. 😄
Genau das ist ActivityPub – kein Konzern entscheidet, wer deine Inhalte sieht. Klingt utopisch? Läuft seit Jahren.
Das Fediverse ist kein Produkt. Es ist Infrastruktur, die Menschen gehört.
#Fediverse #ActivityPub #Dezentralisierung #Mastodon
How to Install #Pleroma on #Ubuntu #VPS (5 Minute Quick-Start Guide)
This article provides a guide demonstrating how to install Pleroma on Ubuntu VPS.
What is Pleroma?
Pleroma is a free, open-source, self-hostable microblogging server that speaks the #ActivityPub federation protocol—so your users can interact with people on other #Fediverse platforms (e.g., Mastodon) while you keep full control over your server ...
Continued 👉 https://blog.radwebhosting.com/how-to-install-pleroma-on-ubuntu-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.raddemo.host #selfhosted #letsencrypt #selfhosting

Using Claude Code to build an ActivityPub implementation for Indiekit, based on Fedify, was the easy part. (and it was a lot of fun 😊)
Building the UI to actually consume ActivityPub content, and layering a Mastodon-compatible API on top of it that works with existing apps and plays nicely with other AP implementations… that’s the real challenge.
Eating FEPs for dinner and reading how other implementations do things is how you realize just how much work is still ahead — and how many pain points are still unresolved.
Right now, my Indiekit blog has:
IndieWeb (Micropub, Microsub, Webmentions)
ActivityPub (server + reader)
If I wanted to self-host my own ATproto PDS, I’d also need to build an “AppView” to consume Bluesky content.
So I’d end up with:
one reader for RSS (my current Microsub)
one reader for ActivityPub (my native, still ugly AP reader)
one reader for ATproto
That’s a lot of readers for different data streams coming from different protocols.
At some point I thought: what if I just used my Microsub UI to consume everything — not just RSS/Atom/JSONFeed/h-feed?
Since Microsub already supports channels, I figured I could inject an AP timeline into a Microsub channel.
That idea fell apart pretty quickly.
RSS and h-feed from IndieWeb sites are straightforward. I know I can reply, like, repost, or bookmark because the other side supports the same interaction model.
But the moment I had to deal with ActivityPub — likes, boosts, replies — everything became different. The Microsub plugin would have needed so many protocol-specific features that my implementation would drift far from other Microsub implementations.
And I really didn’t like where that was heading.
Microsub turning into a universal ingestion layer for everything?
That felt like a guaranteed mess.
So I drew a line: Microsub stays scoped to RSS/Atom/h-feed/JSONFeed. That’s it.
And yet… I’m still torn.
Because instead of one unified UI to consume RSS, ActivityPub, and ATproto, I’m now building three separate readers.
And that honestly feels like a huge waste.
So I’m dumping this conundrum here.
Maybe somewhere between the Fediverse and the Atmosphere, someone has already figured this out — or at least has a better idea.
Do you?
🔗 https://rmendes.net/notes/2026/03/31/a9598