I'm curious what other devs think about this.
-
@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...
@mariusor Yes, I'm seeing it in a real server while doing C2S testing/exploration. In this case, the server can handle Note and Article, in general, so I don't the rationale yet for the conversion. It's in pre-release code so it may or may not be intentional.
-
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)?
@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.
-
@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".
-
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)?
@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.
-
@mariusor Yes, I'm seeing it in a real server while doing C2S testing/exploration. In this case, the server can handle Note and Article, in general, so I don't the rationale yet for the conversion. It's in pre-release code so it may or may not be intentional.
@mariusor @steve I can see this happening. I originally wrote GnuCrusty in 2003 and now I'd like to expand my community's reach by retro-fitting AP support. GnuCrusty users can write Manifestos, and other uses can reply with Grievances, so those are a great match to AP Article and Note respectively. But I have a Manifestos table and a Grievances table. There's no equivalent to AP Image, so if a C2S user posts one of those, what am I supposed to do? The least worst answer is, munge it into the Manifestos table (after a 300 page flame war in 2012 the community decided that art need not be ASCII, so the schema supports images there). So you see exactly the effect you describe.
I'm just going to tell all my users that if they use a third-party C2S client, they might see unexpected results. Instead I recommend they use the official GnuCrusty client, available for both FreeBSD and Devuan. Not a big problem.
-
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 @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 #ActivityPub 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.).
-
@smallcircles @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 #ActivityPub 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.).
@smallcircles @jerger I feel like using C2S client and S2S server is a bit more precise than "app" for this thread. At this point, I haven't been able to determine how you define "app".
-
@smallcircles @jerger I feel like using C2S client and S2S server is a bit more precise than "app" for this thread. At this point, I haven't been able to determine how you define "app".
Yes, I would highly discourage the use of "app". It is why I scare quoted it, but "app" is common language when people talk about the fediverse. "App" is a neat container concept that fits the full scope of ones own FOSS project, but on the fediverse - a growing heterogeneous and interoperable social network - one becomes highly dependent on the foundational network communication layer based on #ActivityPub, and any fedi FOSS developer should be concerned beyond direct project scope, and pay attention that this foundation evolves healthily. This unfortunately happens unsufficiently, and only a very small number of people try to get the ecosystem as a whole to higher levels, volunteering time where it does not directly benefit their own projects. Think @silverpill for the #FEP and @evan for #SocialCG.
Cool find yesterday was that @HolosSocial rather than C2S has a "full AP server" client-side, that communicates with a Websockets tunnel to a dedicated relay server.
-
Yes, I would highly discourage the use of "app". It is why I scare quoted it, but "app" is common language when people talk about the fediverse. "App" is a neat container concept that fits the full scope of ones own FOSS project, but on the fediverse - a growing heterogeneous and interoperable social network - one becomes highly dependent on the foundational network communication layer based on #ActivityPub, and any fedi FOSS developer should be concerned beyond direct project scope, and pay attention that this foundation evolves healthily. This unfortunately happens unsufficiently, and only a very small number of people try to get the ecosystem as a whole to higher levels, volunteering time where it does not directly benefit their own projects. Think @silverpill for the #FEP and @evan for #SocialCG.
Cool find yesterday was that @HolosSocial rather than C2S has a "full AP server" client-side, that communicates with a Websockets tunnel to a dedicated relay server.
@smallcircles @silverpill
@HolosSocial Holos Social is interesting, but to avoid confusion, the phone app is not a "full AP server". It can't federate without an external relay server, for example. Although it combines both client-like and server-like functionality, I don't see it as an alternative to C2S. With C2S I'd be able to access my account/actor from a phone, a tablet, and desktop and laptop computers with different clients. Holos Social binds the actor to a single phone IIUC. -
@smallcircles @silverpill
@HolosSocial Holos Social is interesting, but to avoid confusion, the phone app is not a "full AP server". It can't federate without an external relay server, for example. Although it combines both client-like and server-like functionality, I don't see it as an alternative to C2S. With C2S I'd be able to access my account/actor from a phone, a tablet, and desktop and laptop computers with different clients. Holos Social binds the actor to a single phone IIUC.Yes good to mention, I was out of chars. It becomes I guess like a local-first S2S on the client-side, tied to compliant Relay servers that facilitate the tunnel.
Perhaps @HolosSocial can enlighten us for their project, but such a set up should not necessarily bind to a single client.
-
Yes good to mention, I was out of chars. It becomes I guess like a local-first S2S on the client-side, tied to compliant Relay servers that facilitate the tunnel.
Perhaps @HolosSocial can enlighten us for their project, but such a set up should not necessarily bind to a single client.
Btw @HolosSocial I really
love the clean documentation style of your "How it works" page, to outline various use cases. Great work! -
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)?
@steve This is really interesting.
I see a few cases. One is an ActivityPub API façade for an existing CMS, like Drupal or WordPress. The underlying system only stores Articles, so it tries to fit any input into that format. It might also take a Create/Image and return an Article with an embedded image, say.
-
R relay@relay.an.exchange shared this topic
-
@steve This is really interesting.
I see a few cases. One is an ActivityPub API façade for an existing CMS, like Drupal or WordPress. The underlying system only stores Articles, so it tries to fit any input into that format. It might also take a Create/Image and return an Article with an embedded image, say.
@steve I could also see if the server is checking the content type of the payload, and changing it on the fly. For example, a Create/Image with an MP4 movie as the payload, and it changes it to a Video. In the case you're explaining, maybe the Note has many paragraphs, and the server changes it to an Article to match the expectations for that type.
-
@steve I could also see if the server is checking the content type of the payload, and changing it on the fly. For example, a Create/Image with an MP4 movie as the payload, and it changes it to a Video. In the case you're explaining, maybe the Note has many paragraphs, and the server changes it to an Article to match the expectations for that type.
@steve Finally, just an opinionated server developer -- "there's no difference, everything should be an Article."
-
@steve Finally, just an opinionated server developer -- "there's no difference, everything should be an Article."
@steve In a way, the server is the most responsible for the object long-term -- it stores and serves the data, assigns it an id, provides security, and so on. It also maintains a long-term relationship with the user, including the user's preferences.
But the client is closer to the user, in the moment, and may more accurately represent the user's immediate needs and wants.
-
@steve In a way, the server is the most responsible for the object long-term -- it stores and serves the data, assigns it an id, provides security, and so on. It also maintains a long-term relationship with the user, including the user's preferences.
But the client is closer to the user, in the moment, and may more accurately represent the user's immediate needs and wants.
@steve I'd say, don't do this if you don't have to.
-
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)?
@steve i would probably think my outbox was broken or malicious or not doing compliant^1 activitypub.
^1: depends on a conformance profile to be meaningfully defined, but "publish what i POSTed" seems to be a reasonable enough expectation in the minimal case...
