NodeBB

@julian @mooooooo

> a "Mastodon-ism". It's not strictly right

actually it's not wrong, especially when/because the key is a fragment of the returned document.

you're supposed to get the document and then *find the graph node that matches the input id*.

i suspect some implementations don't recognize that they need to do this, and they just assume that the key is *always* at $.publicKey.publicKeyPem or at $.publicKeyPem. that's incorrect.

@julian If you want to be fully accurate, you can consider my "WebFinger ID" to not be trwnh@mastodon.social or acct:trwnh@mastodon.social but rather https://mastodon.social/.well-known/webfinger?resource=acct:trwnh@mastodon.social (which is linked to https://mastodon.social/users/trwnh via rel=self)

@julian You're not wrong -- it's just generally not considered "authoritative".

Compare to DNS via the authoritative nameserver, versus DNS via a public resolver. dns:trwnh.com is different than dns://8.8.8.8/trwnh.com in that the latter is explicitly resolved via Google, or dns://1.1.1.1/trwnh.com to resolve via Cloudflare.

@silverpill @mike

> What's important is that "post" is not an activity.

I don't see why this is important. In my view activities are posts. If Mastodon et al disagree, that's not my problem.

Also, the context can be anything. I don't see why a 2nd "contextHistory" property is necessary, nor am I entirely clear what it's supposed to mean semantically...

@steve @reiver it could also be resolved in AS2 itself by fixing the Relationship type and/or by making Link no longer disjoint, but we'll see what happens in the coming months i guess...

@steve @reiver sadly as:published is defined for Object, not Link. since they're currently disjoint this won't be valid. i think a Relationship is the next closest thing, but that has its own open issues right now...

@reiver I guess thinking about it a bit more, the reason it can't really be Follow or Accept Follow activities on its own is that any future Reject Follow may or may not exist without your knowledge. So there needs to be an entity separate from the activities to act as a sort of "record" of the current state inherent to a resource rather than a "record" of the state change inherent to some action.

@smallcircles @reiver Sadly the as:Relationship concept is underdefined and underutilized (and arguably duplicative of as:Link).

I don't think Follow makes *everything* into a microblog, though. By default, the Follow does nothing, actually. Even when you Accept Follow, it just adds them to the followers collection. You have to address and deliver to the followers collection for it to mean anything. You are free to address or deliver to arbitrary audiences that *don't* include your followers.

@reiver Having an explicit notion of a "follower relationship" or a "subscription" is useful for other reasons, too -- like, say, being able to specify which activities one is interested in receiving. Or the datetime of last successful delivery, so that inactive followers can be marked inactive instead of destroying the follow relationship entirely.

@reiver FWIW, I actually think that a collection of subscriptions / "follower relationships" is needed for other reasons! Mainly, to help with desync issues in follower state that plague the fediverse today in practice. (I know in a lot of cases people are interested in knowing directly "who is a follower" and not indirectly via "which follower relationships exist", but the former is currently broken and the latter would fix those issues.)

@reiver This is claiming the actors themselves were published at the given datetime, which is probably not what you want.

I think what you want is a collection of actual follower/following relationships, or possibly a collection of Follow activities, or possibly a collection of subscription records. Those can have a "published" datetime and be understood correctly as when the relation was created (instead of when the actor was created).

@julian @thisismissem @technical-discussion Note that a community's attributedTo doesn't work for anything outside of communities, but a moderator can be declared for any object.

Right now, attributedTo.inbox is the last option to send your moderation activities. There are probably more relevant options to try first. The work is to identify those options and make them consistently discoverable. See "Delegated control" here: https://github.com/swicg/activitypub-trust-and-safety/issues/24#issuecomment-4365331657

@Profpatsch @julian i've been doing some trust and safety TF work to explore/develop a bidirectional link between actors and moderators/hosts, yeah. mostly in the context of "where to send moderation related activities" (so you don't Flag a user to themselves if there's a better option), but also could be used for authorizing Update/Delete activities.

alternatively, the problem would not be there if service actors messaged each other for more explicit syndication...

@julian oh dear, these couple of mentions seem not to have made it across. do i need to also mention @technical-discussion too?

@julian Really, taking "same origin" to its logical conclusion would mean that every actor MUST have their own origin and therefore their own FQDN. It doesn't make sense for origins hosting user-generated content unless the UGC is very tightly controlled and sanitized. And even that's not a guarantee of safety.

@julian The sending server might not have boundaries to enforce. Especially not along "same origin" lines. This requires agreement on what the authorization model is.

Say for example everyone gets a subdirectory that they "own" -- /~alice/ and /~bob/ have their spaces on the same origin. One authorization model is "anything within this container is authorized". If you don't recognize this, you can't detect that alice and bob have a boundary between them.

@julian You're making a very strong assumption that the remote server is necessarily checking for things it might not actually be checking for.

Neither the "instance" model nor the "same origin" model are enshrined in ActivityPub. This technically falls under "undefined behavior", because AP doesn't define an authorization model. (It suggests ("may") same origin, but that's about it. A lot of things are "at the receiving server's discretion".)

@smallcircles @nik @reiver JSON vs JSON-LD is a red herring tbh. The real question is, "do you recognize that other people might do things differently"? If you do, then you recognize that conflicts may arise, and you can try to resolve the conflict. But if you don't recognize even the *possibility* of a conflict, then it's painful for everyone involved.

@evan i would add that there are several other more actively maintained options, at least: https://json-ld.org/#developers

in the most basic case, expanding the document should make it unambiguous:

- all keys are normalized to full identifiers with exactly 1 possible representation instead of infinitely many
- all values are normalized to JSON
arrays of JSON objects
- those JSON objects explicitly say whether they have an id (Reference) or a value (Literal)

@reiver i think the disjunction between Object and Link was actually unnecessary. https://github.com/w3c/activitystreams/issues/666

i also think there's too much emphasis on types when there really shouldn't be -- it's the *properties* that you end up using almost all of the time. pretty much the only types that actually matter are the Activity types (because you can't infer those).