post (@post@activitypub.space)
Federated private groups (Announce vs Add)
@sk@utsukta.org mentioned in another thread that the way Hubzilla and threadiverse software handle group discussions is incompatible.
It got me thinking about whether that is true. At its core both FEPs (171b and 1b12, respectively) rely on a central "distributor" node to send activities to recipients.
@silverpill@mitra.social did further comparisons in thr text of 171b itself:
Announceactivity is used instead ofAdd.
https://activitypub.space/post/1190
Show Original Post
olukawy (@olukawy@qoto.org)
Рерайт (російською):
__ __ _ __
/ /_____ ____ / /_(_) /__
/ __/ __ \/ __ \/ __/ / //_/
/ /_/ /_/ / /_/ / /_/ / ,<
\__/\____/\____/\__/_/_/|_|
tootik v0.21.0
https://github.com/dimkr/tootik
tootik — це федеративний сервіс нано-блогінгу для «малого інтернету». Він дозволяє брати участь у Fediverse через клієнти Gemini, Gopher або Finger, роблячи екосистему легшою, приватнішою та доступнішою.
Інтерфейс tootik зводить контент до базових елементів — тексту та посилань, передає користувачам контроль над тим, що саме вони бачать, і навмисно «уповільнює» взаємодію у Fediverse, щоб вона відповідала темпу малого інтернету.
Це єдиний виконуваний файл, який одночасно реалізує федерацію (через ActivityPub) і фронтенд (через Gemini), тоді як SQLite відповідає за збереження даних. Проєкт розрахований на легкість і ефективність — невелику спільноту можна розмістити навіть на дешевому сервері. Код орієнтований на простоту модифікації.
tootik підтримує лише невелику частину ActivityPub і, ймовірно, не повністю відповідає специфікації.
Changelog:
https://github.com/dimkr/tootik/releases/tag/v0.21.0
#Gemini #Fediverse #ActivityPub
Show Original Post
info (@info@social.fedimtl.ca)
🎤 Focus conférencière : Christine Lemmer-Webber @cwebber Co-fondatrice du @spritely et Co-auteure du protocole #ActivityPub, construisant la prochaine génération de technologies réseau décentralisées.
🎟️ Billets en présentiel et en webdiffusion : https://fedimtl.ca/
#FediMTL #Fédivers #WebSocial #SouverainetéNumérique
Show Original Post
i47i (@i47i@hachyderm.io)
The fediverse now has a TikTok alternative called Loops by @dansup. Open source, federated via ActivityPub, funded by NLnet and community donations instead of venture capital. You own your content and can self host. Beta is live and the iOS app just hit the App Store.
#Loops #JoinLoops #Fediverse #ActivityPub #OpenSource #ShortVideo #TikTokAlternative #TikTok
Show Original Post
notes (@notes@fedi.mandarynki.eu)
Honestly, it'd be nice if git servers would be federated in some way with e.g. PRs, Issues, and ofc core functionality of committing... Implementing such stuff within only Forgejo itself would bring the servers and users closer together with self-hosted and the big codeberg (saying this as a self-hosted invite-only forgejo server user :>)
#forgejo #git #federation #activitypub
Show Original Post
spla (@spla@mastodont.cat)
Quin progrés més potent li he donat al codi del servidor appy en els darrers dies.
- seguir etiquetes
- veure l'historial d'edicions dels tuts, amb les imatges i tot!
- obtenir el tut a qui respon l'usuari seguit (imprescindible per a entendre el context)
- mostrar els tuts d'usuaris no seguits impulsats per usuaris seguits.
Ja queda menys per acabar el projecte començat des de zero💪🏼
https://codeberg.org/spla/appy
#appy #python #fastAPI #ActivityPub
Show Original Post
admin (@admin@mastodon.raddemo.host)
Deploy #Castopod on #AlmaLinux #VPS
This article provides a production-ready, step-by-step guide to deploy Castopod on AlmaLinux VPS using Nginx + PHP-FPM + MariaDB + HTTPS.
What is Castopod?
Castopod is an open-source #podcast hosting platform designed to give podcasters control over their content while supporting the latest podcasting innovations, such as Podcasting 2.0 ...
Continued 👉 https://blog.radwebhosting.com/deploy-castopod-on-almalinux-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.raddemo.host #selfhosting #selfhosted #opensource #fediverse #activitypub #podcasthosting
Show Original Post
radwebhosting (@radwebhosting@mastodon.social)
Deploy #Castopod on #AlmaLinux #VPS
This article provides a production-ready, step-by-step guide to deploy Castopod on AlmaLinux VPS using Nginx + PHP-FPM + MariaDB + HTTPS.
What is Castopod?
Castopod is an open-source #podcast hosting platform designed to give podcasters control over their content while supporting the latest podcasting innovations, such as Podcasting 2.0 ...
Continued 👉 https://blog.radwebhosting.com/deploy-castopod-on-almalinux-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.social #selfhosted #opensource #podcasthosting #selfhosting #activitypub #fediverse
Show Original Post
archives (@archives@neon-blue-demon-wyrm.x10.network)
FEP-171b: Conversation Containers Won’t Work
So, I took a look at this:
This document specifies a model for managing conversations in ActivityPub network. It is based on the implementation of Conversation Containers in Streams.
In this model conversations are represented as collections controlled by a single actor. Such conversations take place within a specific audience and may be moderated.
FEP-171b: Conversation Containers
https://fediverse.codeberg.page/fep/fep/171b/
TL;DR: It won’t work.
The proposal introduces authoritative conversation control to ActivityPub by modeling threads as owner-managed OrderedCollection containers. The conversation owner curates replies and redistributes approved activities via Add. Participants are expected to reject unapproved content. The abstraction is internally coherent. The friction appears when this model is placed inside ActivityPub’s federated design.
Here is the problem. ActivityPub does not define enforcement semantics. Servers operate autonomously and apply local policy. A specification can say that implementations “SHOULD reject” unapproved replies. Yet nothing in the protocol requires that outcome. A server that declines to participate can still accept Create(Note) activities directly. It can reconstruct threads from inReplyTo and ignore the container model. In that environment, thread authority exists only where it is voluntarily recognized.
The delivery path changes as well. Under typical federation, actors deliver activities directly to recipients’ inboxes. Here, replies flow to the conversation owner first. Only approved entries are redistributed. Each thread effectively runs through a single coordinating node. Availability now depends on the owner’s server. If it is offline or slow to redistribute, the conversation stalls. Different redistribution behavior across instances can also produce divergent views of the same thread. This is a structural shift in how information propagates.
Ordering and consistency are less defined than the container model implies. ActivityPub does not specify global ordering or conflict resolution rules. An OrderedCollection provides sequencing, but not append-only guarantees or convergence constraints. Order might reflect author timestamps, owner receipt time, or redistribution time. The owner can reorder, omit, or later insert activities. Other servers may cache earlier states. Without cryptographic sequencing or a log structure that constrains mutation, synchronization relies on local policy rather than shared verification.
Moderation authority also changes. The conversation owner decides which activities become part of the visible thread. That may reduce unwanted replies in cooperative environments. It also concentrates control over inclusion and historical presentation. Because the container remains mutable, integrity depends on trust in the owner. It also depends on how other servers interpret updates.
The harassment issue is not actually solved. A non-adopting instance can continue storing and rendering replies it receives directly. Some servers will display only curated entries. Others will not. Over time, different thread views can coexist without converging.
Compatibility with existing implementations raises practical concerns. Most current systems build conversation views from inReplyTo chains and local storage. Introducing container-centric validation, authenticated Add wrapping, and modified inbox handling would require substantial changes. Partial adoption would produce mixed behavior across the network.
The proposal acknowledges risks such as forged or poisoned embedded updates. It also suggests validation steps. Even with those measures, the container remains mutable shared state interpreted by independent systems. ActivityPub standardizes vocabulary and delivery, but not global state enforcement. This design can improve reply gating among cooperating servers. It does not, by itself, establish authoritative thread state across a federation built on autonomous peers.
The issue with the fediverse is that they want their cake and they want to eat it, too. They like to emphasize that they are truly decentralized and use that as a way to sweep any critiques against them in relation to the AT protocol away. But being truly decentralized is the issue.
The core issue is the federated and decentralized nature of ActivityPub. The problem is that the protocol is built around autonomous servers that don’t have to obey a central authority. Each server applies its own rules and policies. Even if a specification says servers “should” reject unapproved replies, they can still accept and display them. The authority is voluntary and not enforceable. The major limitation is that state is not globally enforced. There is no mechanism to ensure that all servers see the same thread order or content. A container can sequence posts. Other servers can reorder, omit, or cache different versions. Without cryptographic or append-only logs that every node verifies, synchronization relies entirely on local trust rather than any shared enforcement.
Partial adoption makes it even more of a clusterfuck. Some servers might implement the new authoritative-thread model, while others won’t. So threads will diverge across the network, and harassment or unwanted content can still appear on servers that do not participate. The decentralized and federated design fundamentally limits any attempt to impose global authority.
No, I am not joining in on the thread, because ActivityPub devs are especially nasty. That is why no one wants to fucking work with them. That is why it’s so fucking underdeveloped.
I was going to put this into this post, but I realized it would get too long:
https://neon-blue-demon-wyrm.x10.network/archives/16790
Show Original Post
strypey (@strypey@mastodon.nzoss.nz)
It's probably less of a problem now that the fediverse is much bigger (than it was 5 years ago). But one of the things I've heard puts newbies off alternative social apps/ networks is too much meta-discussion of the apps/ networks themselves.
Maybe we could agree on a standard way of tagging this stuff (eg #DevMeta)?
(1/2)
#fediverse #FediverseDev #ActivityPub
Show Original Post
khleedril (@khleedril@cyberplace.social)
This is a conversation I've been wanting to see for a long time. As things stand you have to develop ActivityPub specially for every service you want to talk to, because of all the implementation inconsistency. I hope we can converge on a simple solution soon.
https://hollo.social/@hongminhee/019c38dc-0b32-7bb8-ad96-936627f2a2c0
Show Original Post
display (@display@tupambae.com)
@harryhaller
feedback!
thx.
\\ tira cohetes
fediTecInfo:
Um das Bild zu sehen oder den Video (attachment) harry?
Das Bild liegt auf einem #friendica server, Eigentum von @scriptkiddie, ist aber ganz offensichtlich bisher frei verfügbar. Nur wenn mensch den Server direkt besucht verlangt dieser das eine Identifizierung notwendig ist. Theoretisch können wir friendicans unsere Server gegenseitig besuchen und uns identifizieren, zumindest noch bis vor kurzem.
Der Video wurde von diesem Profil hier als attach hochgeladen. Jedoch zunächst als Test an einen reduzierten Circle von #activityPub Kontakten (mastodon), friendicans, und #Diaspora (Protokoll) Kontakten.
Es kann gut sein das aus diesem Grund jenes [attach], das sowohl als solches als scheinbar auch dezidiert in jeweiligem Archivformat, zum Beispiel [video], [audio] oder auch einfach nur als [embed], eingestellt werden kann, nur für Mitglieder jenes Zirkels und Kontakten zum Zeitpunkt der Veröffentlichung zugänglich ist. Bei Bildern können diese Einstellungsoptionen jederzeit verändert werden. Im activityPub Netzwerk federieren diese Updates früher oder später, das hat wohl mit den Caches der Server zu tun. Diaspora übernimmt diese Veränderungen höchstwahrscheinlich gar nicht. Das camo System von denen ist mir ein Geheimnis mit sieben Siegeln.
Irgend wann werden es einfach zu viele unterschiedliche Details.
Deshalb auch das verspielte Testen hier, wie sollen wir sonst auf einen annehmbaren best case Scenario gemeinsamen Nenner zu kommen.
Ok, let's see how we'll work this learning by doing out!
Bitte die TAZ zahlen WIR ab sofort nicht mehr erwähnen, für die ist das ja Job hier und Notifizierungen haben die bestimmt eh mehr als genug.
Einen Anfangshint haben sie ja jetzt und wenn sie wollen können sie vorbeisurfen und sich auf den neusten Stand bringen.
Ich pack dann mal das hier benutzte Profil @harryhaller@diaspora.psyco.fr ab sofort in jenen Zirkel, dann haben wir wieder neue veränderte Data zum unterminieren und testen weiter, sowohl in alle Richtung wie in dieser Antwort, als auch eventuell in dezidierte Richtungen.
👍
Show Original Post