@jerger @steveSteve Bate

Keeping msgs immutable is a general best-practice, I gather.

In the case you mention it becomes confusing to still use client/server terminology. You have a full actor on the client's side, and when it sends a msg it acts in server/S2S role.

Btw, in that scenario we do not have to make the distinction client + server anymore, as we have just actors communicating with each other. Then we can think in terms of the actor model, and honor its qualities.

A client sending to the server's outbox is then analogous to an actor sending to another actor's inbox. That is a one-way msg exchange usually, fire and forget (esp. in a pure event-driven architecture... which the current fediverse is not). The remote actor is not responsible for keeping the Activity (event) in its server-outbox / actor.inbox. That corresponds to the spec part "may disappear at any moment".

@smallcircles🫧 socialcoding.. @jerger > In the case you mention it becomes confusing to still use client/server terminology.

In this case, I think the terms makes sense in the specific content of clients and servers. There's significant overlap in the behaviors of the two, but there are significant differences too. For example, a client cannot federate and often runs in an environment where it can't expose listening sockets (browser, behind a firewall, etc.).

0

If you have a fediverse account, you can quote this note from your own instance. Search https://social.technoetic.com/users/steve/statuses/116056389827623858 on your instance and quote it. (Note that quoting is not supported in Mastodon.)