"A new challenger appears!"
...
Memes aside, if you are a Fediverse developer, it can be useful to pay attention to what others are doing. Notice what works for them and what doesn't. What their trade-offs are. Etc. And, if there is anything we can learn from them. And, perhaps even find ways to cooperate towards shared goals.
Remote Inbox Architecture
2/
The Remote Inbox server deals with incoming activities, objects, etc, from other users..
The front-end can get the inbox (and other feeds') data from the Remote Inbox server.
(You'd probably want to store cached data from the Fediverse elsewhere from these two servers, as I've said before. But, that is a separate thread.)
Remote Inbox Architecture
1/
This, the Remote Inbox Architecture, is an architecture for a Fediverse back-end server that I think could be useful.
Here is how it works — there are (at least) 2 servers involved: (1) the main back-end server, and (2) a remote inbox server.
The actor file on main back-end server "points" the inbox to the remote server.
It separates the user's content from the front-end related functionality
...
🎟️ Early Bird tickets for FediCon 2026 are still on sale — don't miss your chance to grab a discounted pass!
Early Bird tickets are only available for a limited time.
We want this event to be accessible to as many people as possible, so we’re also offering a reduced-fare (early bird) ticket option for attendees who need an even lower-cost option.
Join us for a gathering all about the Fediverse, the Social Web, and the people building what comes next.
📅 August 6–9, 2026
📍 UBC campus, Vancouver, BC
🎫 Get your FOSSY ticket, which gets you into FediCon:
https://2026.fossy.ca/attend/tickets/
On moving an actor's content.
4/
Or, instead of using the ActivityPub 'Update' activity —
Couldn't we use the ActivityPub 'Move' activity.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-move
With the "origin" and "target" fields.
Where "origin" contains the old ID URL, and "target" contains the new ID URL.
.
On moving an actor's content.
3/
There a many different conventions we could come up with to allow an ActvityPub 'Update' activity to be used to change an object's "id" field.
We (the Fediverse developer community) just need to pick one that everyone is willing to implement.
For example, perhaps the "origin", "result", or "target" field should be used:
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-origin
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-result
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-target
Or —
...
On moving an actor's content.
2/
Could an ActivityPub 'Update' activity be used to move objects from one server to another server?
Could an 'Update' activity be used to change an object's "id" field?
After all, the "id" is used to identity what is being changed. It is the targeting mechanism.
How can you provide the old "id" to target the (old) object you want to change the "id" of, while also providing a new "id"?
https://www.w3.org/TR/activitypub/#update-activity-inbox
...
On moving an actor's content.
1/
One of the things that comes up on the Fediverse from time to time — is the ability for people to move their accounts.
For example, someone started off at:
＠joeblow＠example.com
But, now wants to "move" to:
＠misterx＠host.example
There is a mechanism to do that.
That mechanism moves their followers, their followees, BUT —
It does NOT move their content over!
That is a problem. Could we address this‽
...
ActivityPub being treated as JSON is a good thing.
5/
JSON-LD has similar complexity to RDF. They are actually related formats.
ActivityPub uses JSON-LD, and thus has the potential for the same type of developer user-experience problems as RSS 1.0.
But I think ActivityPub is its own "RSS 2.0".
Why‽ Because people can and do treat ActivityPub as JSON (rather than JSON-LD).
That is a strength. It makes ActivityPub much simpler and easier to understand than JSON-LD.
@reiver ⊼ (Charles) 
Jonu ☮️ : 🕉️
FediCon