• 4 Posts
  • 61 Comments
Joined 3 months ago
cake
Cake day: July 5th, 2025

help-circle
  • Thanks for clarifying, I figured fashion had at least something to do with it given the number of actively used protocols and services that still use it, XMPP being the one I use the most myself.

    Even on XMPP I have seen several projects to “translate” the protocol into other languages (specifically Rust in one).

    Efficiency makes sense, but then also the number of devs proficient in a language due to shifts in the emphasis of training and education is just as strong a force.



  • Interesting, I have actually used Movim for xmpp chat before but not fully explored its publishing features. This is a good nudge to do so. I wonder how it handles “communities”. I have been tracking XMPP recent development and threads are just now getting support, though they function more like tags in chat streams than like threads in a Lemmy sense in current implementations. It seems like the “Spaces” concept proposed in XEP-0503 would round this out, and I have discussed how Nicolo of Slidge plans to work on this woth the Movim dev team, it would make sense Spaces would much improve the blogging/forum functionality of Movim. I was asking about it for the potential of replacing Matrix/Discord with XMPP.




  • I did not mean to say Jabber is a fascist project. You said “ActivityPub has been a fascist project from its inception.” and I was responding to that. XMPP has end to end encryption protocols and so is not a part of the open web fundamentally.

    GNUSocial was built on OStatus which actually is the closest thing to the tech stack I am talking about in my post. It did not include XMPP/Jabber as far as I can tell. Interestingly the Wikipedia article on OStatus claims that ActivityPub arose out of the OStatus project in order to reduce the complexity of implementation, so another mark towards that explanation, but I’d like to hear more from devs involved.






  • Webmention already exists and is service agnostic and interoperable. My assertion is that protocols for handling the social function of ActivityPub predate ActivityPub’s development and could be unified by a client without creating any new protocols that aren’t already in use, so what is it that ActivityPub is doing better than those protocols that justifies intermediating the social graph with group servers? I’m sure there are good answers to this question, I just want to know what they are with more clarity.


  • If you read the post you’ll note I mention Webmention, email, and XMPP, which all handle bidirectional communication in different ways. Webmention in particular enables implementation of both on-site comments and pulling comments from off-site services to display locally on a post/page, as well as replies to those comments.

    I’m not suggesting RSS alone is sufficient, but rather that existing solutions/protocols appear to exist for the problems ActivityPub seems to be solving, but without the step of intermediating publishing through federated servers. A client could be built tying these protocols together as a social networking front end.

    My question is, what is ActivityPub solving that the combination of these existing services do not? Unidirectionality isn’t it, though someone’s prior comment pointed out the efficiency of push vs pull in terms of content distribution and I do see that point.


  • Good to know.

    Regarding polling efficiency, that makes sense. As I understand it ActivityPub uses a combination of push notifications at time of publishing and pull notifications at time of subscription/query for objects? I can see how offloading that to an instance for multiple users vs every user definitely increases efficiency for content discovery/inboxing. I know there are protocols like websub to add push notifications to blog publishing, but they are required to be done at the publisher/host side. I do see this as a big nudge in ActivityPub’s favor.

    Duration of caching is set by the instance admin I take it?

    At a minimum this is adding the number of instances that federate a given content streams to the multiple of storage needed to host the content, even if that storage is ephemeral. Not so big a problem at 100,000 users, but at 100,000,000 users this is a lot of storage cost we are talking about. Unless somehow the user/client doesnt cache the content they pull from an instance locally on their device when they view it?

    Regarding Authorship, if there wasn’t an issue then ATProtocol devs wouldn’t have made it the cornerstone feature of their network. The ability to move accounts between instances and maintain content control permissions is currently one of the big focuses of development on ActivityPub as I understand it. Also as I understand it many Fediverse instances dont have edit functionaly enabled, meaning once the content goes out it is out of Author control. I’d like to know how delete requests propagate, when the “Object” is deleted does a request to clear cache go out to all federating instances?

    My point was this isn’t an issue when all content is self-hosted, because the author as the host can edit, delete, or migrate all they want and maintain full direct control over the source of that content the client interacts with whenever a pull request comes in. Yes the user Caches the content when they read it, but there is no intermediary copy.




  • This does remind me that I wish that Fediverse clients would have RSS reader functionality built in by default. I have a sneaking suspicion some do and I just don’t know how to use the feature. Effectively allowing people to “boost” aka repost with backlink RSS updates on a Fediverse client would enable most of what a blogger would want from the Fediverse, with the exception of receiving all the comments on the posts they share.

    Bridgy does that, but then it is essentially just a mirror so it does have the server inefficiency of redundant hosting built in.

    That you might say is the fundamental design decision of Activity pub, shifting the hosting burden from a single host to a distributed network of server instances. This enables a more robust network, with instances holding content the users have interacted with regardless of if the original host instance goes down. It also reduces time to load for content after it has beed federated to a user’s local instance, assuming it is closer in proximity and capable enough. At the same time, this makes content ownership and control a challenge.

    Functionally the Fediverse is a public commons with content ownership practically distributed across the network of instances, whether copyright says so or not. Attempts to impose universal author controls on this framework face a lot of dissonance because it is fundamentally at odds with the underlying concept of federation as distributed hosting. The minute a host begins hosting content over which they have no control (such as encrypted posts) the potential for abuse skyrockets.

    Since the popularization of the Distributed Social Network concept I have wondered whether pre-existing content distribution infrastructure like RSS might not be more advantageous as a backbone for social networking, with the development load entirely shifted to the client side and away from protocols. The IndieWeb project is playing with some of these ideas, and I have seen some prototypes online of RSS based social networks, so my question is, what is the fundamental advantage of ActivityPub over the combination of these other existing protocols with longer histories and broader existing implementation? RSS, email, XMPP, etc. Is lower latency really a good enough justification for widely redundant data distribution?

    This question becomes increasingly relevant when it comes to multimedia, and the minute that you offload multimedia to central servers by link embedding instead of hosting within the instance, boom you are back to the old centralized architecture and why are you federating?

    So I am going to pose this question to the Fediverse myself, what is the reason that federated content distribution should be adopted for general use rather than distributed aggregation? That is to say of a client performed with the same features as a Fediverse front end, but all of the content was self-hosted and listed via RSS or Atom with comments handled via Webmention, direct messages via email or XMPP, and moderation handled at the level of aggregation via instances (meaning a user “joins” or “subscribes” to an instance, and that instance provides a ban list, list of feeds subscribed to by its users for discovery, provides a user directory) what would be the features that this type of system would lack that ActivityPub based systems have in place?

    There are three advantages I see, and I’m not completely sure they justify mass adoption vs. the cost of broad redundancy of content and authorship issues.:

    1. Choosing local instance for faster loading, but this only is an advantage after content is brought in for the first time, in which case it actually is slower as first the instance has to pull the cintent and then serve it to the user.

    2. “all” content in the protocol is of the same type, allowing for easier interoperability between clients and services. I’m thinking this is the root of what most people will say is the big advantage of ActivityPub vs. older protocols, but I’d like to hear more about why this is enough of a reason to overcome the inertia of existing mass adoption and support of the alternatives.

    3. It isn’t based in XML, and modern devs don’t want to use XML. As I’m not a coder, I cant say how big an influence this has, but from what I have seen it seems to be a substantial factor. Can anyone explain why?


  • It’s wild to me that Soulseek persists despite being entirely mediated by a single central server. I would have thought it would have gotten the takedown long ago.

    Also the fact that it doesn’t swarm, only does one to one peer sharing is kind of odd to me, but I guess it actually makes some sense in that it constrains the network to being more optimal for smaller files like music and so keeps video off of the platform for the most part.

    Worth noting that the Soulseek Wikipedia page lists a bunch of clients you can use, including Seeker for Android and others for all platforms including Linux



  • I’m going to have to dive into push notification handling, I basically minimize the use of push notifications at my desktop level to only push work related content, and use the notification system of the clients to handle the “recreational” content which leaves me checking lots of platforms separately.

    It makes sense that there should be the ability to create separate profiles with different filters and behaviors at the push notification manager level, I just haven’t thought to look into it before.

    Regarding killer apps for ActivityPub, and unified clients, I have a second idea which I didn’t want to cloud this thread with that seems somewhat inevitable that will require a central portal with access to all services (and accounts?). That is a single publishing UI where the user creates/uploads any piece of content and then it suggests what venue/service/account to publish it on and related add-ons like hash tags, etc. With the Fediverse the APIs are open and multiplatform publishing clients (like FediPlan) already exist, so a level of light ML/AI for publication seems inevitable.

    The next level of this, and what could be a “Killer App” is spontaneously generated affinity grouping via content aware publishing, meaning that the publishing client not only suggests where the posts should go, but also has a metalayer where the publishing clients instances “gossip” about the content being published and then create brand new “spontaneous” venues to publish that content in alongside other similar content being published by other users. Suddenly your text post about a super-niche interest or problem is pooled with posts by other users on the same topic, and bam you have a relevant discussion group of commenters/posters.

    Problems of course arrise from this re:advertisers/promoters as well as unsavory/harmful mutual interests, but to be honest I think this is more of an inevitability than a possibility, so getting ahead to architect it in a way that minimizes potential abuse before the corpos get on it is probably a good idea.


  • Why don’t the highest use rate clients for Fediverse services look like standard browsers? There is a level of pure aesthetic sensibility at play.

    I’m interested in what you mean by your desktop handling your notifications, do you have a central log of notifications you can access via your desktop?

    This is actually a pretty great angle I hadn’t fully thought out, most clients do push notifications, so is what I’m really talking about just a push notification log with the ability to filter for a set of designated sources? That would definitely handle a hefty chunk of what I’m getting at, the rest is basically just a browser skin and some extensions.


  • Yes, thank you.

    The core of my proposal is to minimize the dev burden of a unified platform by utilizing the siloed web clients for content interaction while centralizing notifications/inbox.

    This should please both camps because the platform people will just keep doing the same thing they have been doing, while the browser folks get a single point of interaction with notifications but multiplatform capability on content interaction/graph navigation.