Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Cross-server Interactions in ActivityPub

General Discussion
9 7 27
  • Cross-server Interactions in ActivityPub

    So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!

    ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.

    We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:

    Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.

    Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.

    This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.

    This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.

  • Cross-server Interactions in ActivityPub

    So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!

    ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.

    We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:

    Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.

    Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.

    This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.

    This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.

  • Cross-server Interactions in ActivityPub

    So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!

    ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.

    We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:

    Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.

    Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.

    This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.

    This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.

    @dave @adam this is a great post from @evan on how people can make comments across the fediverse.

  • @evan @evanprodromou Thanks Evan, it sounds compelling and I look forward to reading more! Re “It makes your own ActivityPub server your real home on the Web” -> is the idea that you would host your own AP server (e.g. for me it could be at ricmac.org), or do you think managed services will emerge that offer this as a service? Or is it something you can do with your Mastodon account potentially?

  • @evan @evanprodromou Thanks Evan, it sounds compelling and I look forward to reading more! Re “It makes your own ActivityPub server your real home on the Web” -> is the idea that you would host your own AP server (e.g. for me it could be at ricmac.org), or do you think managed services will emerge that offer this as a service? Or is it something you can do with your Mastodon account potentially?

    @ricmac
    ActivityPub servers capable of hosting your identity at a domain of your choice, rather than the servers' own domain, are going to be a thing. Mastodon today doesn't do that. One of the few that does is @takahe - but it'll become more common for a general purpose "social" server.

    And then there are going to be the special purpose apps, which will also speak ActivityPub - in their domains, or yours, depending on their ops model.
    @evan @evanprodromou

  • @ricmac
    ActivityPub servers capable of hosting your identity at a domain of your choice, rather than the servers' own domain, are going to be a thing. Mastodon today doesn't do that. One of the few that does is @takahe - but it'll become more common for a general purpose "social" server.

    And then there are going to be the special purpose apps, which will also speak ActivityPub - in their domains, or yours, depending on their ops model.
    @evan @evanprodromou

    @osma @ricmac @takahe @evan @evanprodromou i'd add that @gotosocial is a really good option for own-domain activitypub server, too.

  • @ricmac
    ActivityPub servers capable of hosting your identity at a domain of your choice, rather than the servers' own domain, are going to be a thing. Mastodon today doesn't do that. One of the few that does is @takahe - but it'll become more common for a general purpose "social" server.

    And then there are going to be the special purpose apps, which will also speak ActivityPub - in their domains, or yours, depending on their ops model.
    @evan @evanprodromou

    @osma @takahe @evan @evanprodromou

    Osma, just to note that @evanprodromou replied to you and I on his blog: https://evanp.me/2024/04/22/cross-server-interactions-in-activitypub/#comment-942 (and the fact those comments didn't flow through to Mastodon shows some of the practical issues we're dealing with!)

  • @osma @ricmac @takahe @evan @evanprodromou @gotosocial huh, interesting idea...my assumption was that takahe maintained a separate "federated timeline" for each domain it was configured with.

  • Cross-server Interactions in ActivityPub

    So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!

    ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.

    We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:

    Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.

    Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.

    This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.

    This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.

    @evanprodromou I wish we'd also had a url handle to deal with everything. like web+ap:// but supported by everyone and used for everything, not just links.

    https://fedilinks.org/spec/en/6-The-web-ap-URI


Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti
  • 0 Votes
    1 Posts
    11 Views
    More progress on the AP implementation on my site. I got HTTP signature verification on Follow activities working and started the groundwork to migrate from my current instance to my website. Some things I want to do before migrating: 1. Export my archive, I'm especially interested in preserving who I'm follows and bookmarks. 1. For bookmarks: Create a page on my site that links to the bookmarks. 1. For follows: Create an OPML file linking to their RSS feeds and add those feeds to my feed reader. One thing I will miss after I retire my instance is the timeline. I always discover interesting posts and people that way. My plan is to follow RSS feeds for tags that I'm interested in. I know it's not as good or spontaneous as the timeline but it's a way to stay engaged in the conversation. Also, my site effectively will work one-way for now. I don't have a way to receive replies or DMs, nor do I have a way of replying to people directly from my site. Maybe that's something I'll add later on but not a priority at the moment. My main priority at the moment is to maintain a presence in the Fediverse without having to maintain my own instance. I know technically I could just join someone else's instance, but I don't want to create yet another account nor become a maintenance burden for someone else. More importantly though, I want my website to be my digital hub, with protocols like ActivityPub, Nostr, and AT Protocol serving as spokes to reach different networks. My content and identity remain on my site, independent of any single platform. If any protocol or network disappears, my content and identity remain intact.
  • 0 Votes
    1 Posts
    4 Views
    Release v3.2.3 of Ktistec includes two big features:FEP-1b12 Group federationImproved federation with Lemmy and other forum-type servers. Ktistec supports community and thread follow/unfollow, as well as up-vote/like (down-vote/dislike is supported but there is no visual affordance for that yet).FEP-9098 Custom emojisSupport for viewing custom emoji in posts and on actor profiles. Ktistec does not yet support custom emoji creation and management.The full changelog:AddedSupport for viewing custom emoji in posts and on actor profiles.Actor type (Person, Group, etc.) overlay badges on actor panels.Colored fallback avatars for actors without icons.Support for robots.txt.FixedFederation with Lemmy and other servers that support FEP-1b12.Shared inbox support for local actors.Serialization of Undo includes the undone activity.Serialization of Like and Dislike does not.Notify only once for an object's first received activity.ChangedAccumulate metrics by hour for finer granularity.Clean up presentation of public followers/following pages.The next release will include support for Mastodon polls (FEP-9967).#ktistec #crystallang #activitypub #fediverse
  • 0 Votes
    1 Posts
    10 Views
    Week in Fediverse 2025-11-28Servers- tootik v0.20.0- Ktistec v3.2.1- NodeBB v4.7.0- Wafrn v2025.11.01- Loops v1.0.0-beta.5- Mitra v4.14.0- Misskey v2025.11.1- Omnom v0.8.0- PieFed v1.3.5- stegodon: An SSH-first federated blogging platform- linkblocks: A federated network to bookmark, share and discuss good web pages with your friendsClients- Chihu v1.14.0- Phanpy changelogTools and Plugins- feed2fedi v3.4.0- FIRES Server v0.7.0- OwncastLive Panel: A GNOME Shell extension that monitors your favorite Owncast instances and notifies you when they go liveArticles- Git as Federation Transport — Rethinking How Small Social Networks Talk to Each Other- Now witness the power of this fully operational Fediverse!- Fediverse onboarding resources- Owncast Newsletter November 2025- Fediverse Report – #144-----#WeekInFediverse #Fediverse #ActivityPubPrevious edition: https://mitra.social/objects/019aa829-83b6-d369-eedb-8725125ced7b
  • 0 Votes
    5 Posts
    25 Views
    @wjmaggos Yeah, but feel bad for the guy. What's happening is that there is an adversarial relationship developing and Bluesky holds all the cards. This is not going to end well for Blacksky.This has always been the problem with corporate sponsored standards. If the technology host company is not fully and completely committed to open competition with their standard clients it can never work.