I'm curious what other devs think about this. If an actor posts an C2S #ActivityPub Create/Note to the outbox, what would you think if the object created by the server was a different type (e.g., Article)?
Discussion
Loading...
@steve I think I’d be Quite Annoyed if a server did that when the C2S app I’m writing sent a Note. I’m asking it to Create a Note - I expect it to create a Note or fail to create a Note, not do some weird, unexpected third thing.
I could maybe tolerate it adding a second type, but while my code can handle multiple types most ActivityPub software doesn’t seem to accept that kind of thing.
@steve If you consider also peer 2 peer networking as an option, your client might switch it's role and act as a server.
In this case it having such a different inside outside mapping for objects will become confusing.
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".
lets say there is a local-server sending this create/note to a distant-server.
Whatever object distant-server creates internally I am very neutral.
But I am very engaged from
1. viewpoint of local-server I expect to get feedback about a note object & being able to deref a note object.
2. viewpoint of distant-server user I expect to see a object behaving like a note.
In a bottom line - naming a note different makes absolutely no sense at all ...
@steve why should C2S being different ?
I agree with this. The #ActivityPub spec says:
> The server MUST then add this new Activity to the outbox collection. Depending on the type of Activity, servers may then be required to carry out further side effects. (However, there is no guarantee that time the Activity may appear in the outbox. The Activity might appear after a delay or disappear at any period). These are described per individual Activity below.
My expectation as a client is that I find the Activity I just sent in the outbox on the server with the same (Note) payload. If there's translation into Article, then this is a side-effect that comes after that.
Although @steve in the exchange with @mariusor refers to a "generic client" and I wonder what that means exactly.
Specific client / generic server: The client is the "app". Server only 'serves', does not violate client's expectation. It handles the CRUD, 'caching' and addressing, has no side effects that are relevant to the client. Client is in charge, and Activity is an event (it happened, deal with it).
Generic client / specific server: The server is the "app", client not in charge. Client acts like 'front-end' for server functionality. The Activity constitutes a command to be processed. As client I'd expect it to be immutable, and that's probably best-practice too.
Specific client / specific server: Side effects on server constitutes a different "app" than on the client. Client sends an event, server processes, may trigger further server events that may address the client. I'd still expect the event to be immutable, Create/Note stays the same.
@smallcircles @jerger @mariusor I meant "generic" primarily to mean it's not a client for a specific server implementation. In this case, it is a C2S testing client so it is not specific to a particular user domain either. In the first sense of "generic", I could imagine a media publishing app (images, videos) that's not tied specifical to PixelFed or PeerTube (as examples). Or a "generic" microblogging app. The latter is where the Note to Article conversion would probably be an issue.
Guess this is a general area where due to the lack of clear protocol layering there's much confusion in overall terminology usage.
The whole idea of an "app" is not part of #ActivityPub itself. It is a leaked abstraction on what devs think they offer ("I build an app for my users").
There is no "generic" microblogging app, unless there exists an agreement for the specification of said app. PixelFed is a spec, PeerTube is another spec in different domain. A generic microblogging app would live where? As FEP? Collection of FEP's? W3C Note giving a 'specification profile'?
1+ more replies (not shown)
@steve from what point of view is this question?
What would I think as the user that sent a Create/Note? Probably would not care/know.
What do I think as a server that receives a Create/Article? Makes no difference. Would the canonical version of the saved object also be Article if I dereference it?
As a spec implementor and user, I would probably be upset that my intent was not preserved.
@mariusor Like I said, this is a C2S context. Let's say they do know. Your opinion is that the user should not care? I'm guessing there are other kinds of C2S server-side changes that you'd believe they would care about (changing content, addressing, etc.).
@mariusor And I'm thinking of a general C2S client (not one developed by the server developer for that specific server). The client developer might care for technical reasons. For example, some servers don't support Article S2S federation so the example I described (converting Note to Article in the server) could have undesired results.
@steve the problem as I see it is only with the "misrepresentation of the user's intention". Which might, or might not cover the aspect that you referred to...
@mariusor Like you said, I'm not sure the user (rather than the client dev) cares about details like the AP object type. However, they may care from a UX perspective if their messages are silently dropped (during S2S federation because the type was changed). And if they do care, they'll probably complain to the client developer who didn't cause the problem. 😉
@steve but did you actually observe this behaviour in any servers? What made you ask the question?
To me it sounds very implausible, because the server *actively* needs to do something instead of piping the received activity directly to its recipients. Is it a case of "the server doesn't render Note objects" so they silently convert to something they do?
Even that's implausible to me, because the same code can be used to render both... 
1 more replies (not shown)