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

How does tags.pub have 143,000 monthly active users (based on fedidb.com)? I know each hashtag is an actor in the tags.pub design, but are there that many unique hashtags in the Fediverse (> 500,000 total "accounts"). Is this artificially inflating the number of accounts and MAU in the FediDB statistics? Just curious...

/cc @evan

@maxleibman @evan > Who had “hashtag apartheid” anywhere on their lists of reasons the Fediverse didn’t work?

👋

@mariusor @silverpill Object type-specific Accept activity types 👎 It appears to me that some of these concerns are implementation-specific (activity processing and caching techniques) and some are related to not understanding the spec (wrt partial objects).

@evan @reiver Speaking for myself, I'm not interested in compelling powers. I think MUST is valuable not because it forces developers to behave, but because it defines the behavioral contract we can test, reason about, and build on (with interoperability guarantees).

@evan @reiver Maybe we need a read-only and write-only subprofiles? But what about an C2S server that doesn't allow reading the inbox nor posting to the outbox (like Mastodon) but still satisfies the MUST requirements in the profile?

@evan @reiver I wasn't thinking of something instead, although I can imagine implementations that use pre-shared "app tokens" or HTTP Basic Auth (as examples). The motivation for the question is the C2S list maintained by @smallcircles. It seems like most of those are not what I'd think of as C2S (Social API) servers.

@evan @reiver An actor not being able to read their own inbox disqualifies it as a C2S API for me (even a read-only one).

@reiver Thanks. I knew there were some related git issues, but I didn't know Evan had created a document for his proposals. Based on that document, servers that don't support OAuth2 auth code grants would not be considered C2S (Social API) servers. It's interesting to me that there's no requirement for outbox POST or inbox GET. It seems like Mastodon would satisfy these C2S server requirements (OAuth2 auth code grants, bearer tokens, 429 rate limits, etc.), but that doesn't seem correct to me.

What would you consider the minimal features to be considered an #ActivityPub C2S server? Support for inbox GET, outbox POST, OAuth2, proxy endpoint, ... ?

@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.