Notices by Steve Bate (steve@social.technoetic.com)

@evan @jalcine Thanks for sharing your rationale for using "ActivityPub API". Given "client to server" is used 22 times in the spec and "ActivityPub API" (which could also apply to the server to server REST API) is not mentioned at all ("Social API" is mentioned once), it could be considered more insider jargon than "client to server" (C2S). I've tried using the various terms in discussions and "C2S" or "client to server" tends to lead to less confusion. I suppose it's one of those YMMV topics.

@evan @jalcine Just to be clear, I refer to it as ActivityPub C2S API or C2S protocol (which covers both read and write capabilities), not just C2S.

@silverpill An duck rule like the following would fail...

❌ if an object has an inbox or outbox, then it is an ActivityPub actor.

for objects that aren't actors but have valid LDN inboxes (the same property as AP actor inboxes).

Although *maybe* the outbox makes sense (only actors perform activities), the claim that actors are the only AS2 type allowed to have an inbox is not consistent with the Linked Data Notifications (LDN) origin of the AP inbox. LDN allows any entity to have an inbox. Unfortunately, this breaks some actor duck typing techniques. #ActivityPub

@silverpill @benpate For this specific BYODomain use case, the WebFinger service is not the host for any AP tenants and their associated users/actors. Therefore, it's not related to the multitenancy topic. It's more like a fediHandle-to-URI "redirect". In the related concepts discussion, the FEP is referring to BYODomain in the context of ActivityPub actor ids.

@strypey@mastodon.nzoss.nz @benpate @silverpill @takahe Just saw this...

> except Takahē and BandWagon suggests it's hard to find

Other multitenant-capable sofware (not the same as BYOD), are Fedify, FIRM, and Vocata.

@silverpill @benpate I don't understand your point. Can you share your definition of "BYOD"? As we've discussed previously, I've brought my own domain to my self-hosted Mastodon server instance, but that doesn't make it an implementation (or instance) with multi-tenant capability.

@evan It looks like a bug. The example appears to be the Announce sent by the relay server rather than from a relay client. If you know the correct example, please submit a PR at https://codeberg.org/steve-bate/fep. Otherwise, I'll update it when I have some time. Thanks for the report. (BTW, I saw this post by accident. Where did you get that mention address for me?)

@evan Do you have a link to the process description for submitting something like an FEP under the SocialCG CLA?

@evan @trwnh @hongminhee I think he was referring to the GitHub project description: "Activity Streams 2.0 for Node.js (this package is not actively maintained..."

@trwnh @silverpill I agree about the name and the extraneous external FEP references. Even if focused on side-effects, a properly specified FEP on this topic would be a challenge.

@silverpill @mariusor @trwnh In principle, I like the general idea, but I think it's misleading to call this an "ActivityPub" server FEP since it doesn't conform to the ActivityPub specifications. You also recommend (require?) using the `result` property to describe server side-effects, but you don't describe *how*. I don't know how you expect to "force clients to specify them".

@silverpill @mariusor @trwnh
> This FEP introduces new requirements to ActivityPub, and I will probably add more in the future. Does that make it non conformant?

Not at all. I was referring to the `Add` without an `object` to create a collection (instead of Create/Collection, I assume).

@silverpill @mariusor @evan @raphael "you have an EmojiReact activity which server should add to object's emojiReactions collection as a side-effect."

It's a direct rather than side effect, but how is that different from Add(object=EmojiReact, target=object_emojiReactions)? A generic server could support that.

@silverpill @evan @raphael Several generic AP server implementations have been built, so I don't know what you mean by the side-effect comment. Note that my mental model of a generic server doesn't implement any domain-specific behaviors in the server, but only side-effects specified by AP (and extended generic C2S support). There are also simpler ways to design servers so that content isn't tied to a specific server (with different tradeoffs than FEP-ef61). That's a long discussion...

What if... you had one Fedi account on a generic headless #ActivityPub server that simply hosts and federates your data... and had C2S UIs for microblogging, long form writing, media editing and sharing, link aggregation, games, fitness tracking, and so on, that all used that same Fedi account. Technically, it's a similar concept as ATProto (but no relay and app view) and Solid Pods (but no RDF).

It seems possible... if we can improve the AP C2S API/protocol sufficiently.

@smallcircles @mariusor @evan C2S is described (too loosely, but…) in the ActivityPub spec. There is a client and server aspect to C2S. A C2S client is software that uses that protocol/API to interact with an ActivityPub C2S-capable server (general or domain-specific). When I refer to an ActivityPub Client, I mean software using C2S rather than consumers of ActivityPub-related data in general.

@mariusor @smallcircles @evan C2S has client-side and server-side aspects (different, but overlapping, behavioral requirements, etc.). Both sides consume *and* produce AP data (pull and push for S2S, currently only pull for C2S). Fetching AP data (URI dereferencing) is common to both C2S and S2S.

@mariusor @smallcircles @evan I *think* it’s
clear. I agree it’s a kind of “client”, just not necessarily a C2S client.

@mariusor @smallcircles @evan No animosity here. However, I’m not sure how to explain it more clearly. I’m referring to C2S as described in chapter 6 of the ActivityPub specification (and the conformance profiles in Section 2.1). It sounded to me like you’re using a more general definition of “client”, which is fine, just different in significant ways (if it only dereferences and renders AP data).