it's only inefficient if you care about like/dislike/share counts. i am fundamentally disagreeing that those activities should be considered part of a conversation. it adds nothing to the conversation to just tell everyone "i like this" with zero additional input to the conversation. now, if you wanted to clarify and say "i like this because ..." then maybe you actually are contributing to the conversation. you'd do that by putting content
on your Like, which turns it into a "post". (posts dont have to be Notes or Articles. activities can be considered "posts" if they have content
.)
trwnh@socialhub.activitypub.rocks
Posts
-
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)? -
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?disagree that
context
should contain likes and dislikes. i think those should go in collections likelikes
or an extension-defineddislikes
.but also,
context
is agnostic to what it contains. this is why i was thinking of maybe defining new types to signal that the collection should contain "posts" (objects that havecontent
) only, or if it can contain other non-"post" objects like Like/Announce/etc activities.the main mechanism for deciding what goes in a context collection is more or less "whatever declares that
context
and gets delivered to / added by the authority" -
NodeBB v4.0.0 Betadepends what you're trying to assert or prove. signing http messages in general is something that could still be done, if your goal is to assert who made the http request. embedding a signature on a document is fine, if your goal is to assert who authored the document and that the document has not been modified. (or you could limit it to just the content, or some arbitrary metadata, or whatever.)
for any key-based verification methods, you need to be wary of key reuse. it's possible for the keyId to be different, but for the key material to be the same as some other key. you can generally tell that an actor is represented by a key, and then the key can claim to be controlled by that actor, but you don't know if the associated private key is in fact being controlled by other actors unknown to you, or if other actors are represented by the same public key material. so some level of deduplication of public keys may be needed before you can authenticate an identity. of course the "real" problem is that the keys are most likely custodial, and rather than try to discover and enumerate every single actor from a given domain, most implementers just assume that any keyId on a given domain is in reality controlled by the software running on that domain. (the same-origin policy, basically.)
so in conclusion, if you're trying to know that a given identity is behind the request, then the best you can tell right now is that their server is making the request. whereas with stuff like fedcm oidc or fedcm indieauth, the request is happening in the browser.
-
NodeBB v4.0.0 Betaat the risk of igniting a protocol war, i'm not sure OpenWebAuth is the best solution for cross-domain identity, for a few reasons:
- it has reliances on older and not-widely-implemented technologies. the rest of the tech space is converging on oauth and related technologies, and not the old http signatures cavage draft stuff. using webfinger to look up a "magic endpoint" for the user, and again to look up the "root url" to find a bespoke "token endpoint", is simply duplicating a lot of work that has been standardized in other specifications.
- it makes no proper distinction between the key and the actor. the problem with current public key infrastructure in fedi is that keys are not only custodial, but they may be shared across the entire server. so anyone else on your server may be able to access remote resources "on your behalf", as it were, in the case that a single keypair existed and was declared for every single actor on the local origin.
- it relies on query parameters which can easily leak into logs or get copied-and-pasted accidentally by a user. the proper place for authorization tokens and such is in the Authorization header (which does not generally get logged).
- it assumes that there is a "home instance" and does not support the possibility of external identity providers that are not themselves fediverse instances.
-
Re: 400e, 7888, and conversation containersI don't think "obsolete" is the right framing here. You can mostly consider Conversation Containers to be a synthesis of 7888 and 400e, and if they dropped
target
on the object (invalid) and on the Create activity (undefined), then it would basically be 7888. -
The current state of context resolutionI would just make the
context
collection have anoutbox
! Theitems
/orderedItems
are the objects and theoutbox
contains the activity log. -
Handling "410 Gone" when retrieving an actorYou could do what Reddit does and just leave the posts up but pointing to a tombstone user. If you've ever seen a post attributed to
[deleted]
then you know what I'm talking about.The problem with that is it possibly (probably¿) violates social expectations around what an account deletion does. Arguably this could be solved by an extension property or type like "DeleteAllCreatedObjects" or whatever. But some implementations might not be able to do that because they don't keep track of objects by who created them. The other option is to support deleting multiple objects at a time? This stuff is best-effort, though, so it might fail for some of the objects.
-
An FEP for Follow/Accept mechanics?julian:Receipt of an Accept is asynchronous, so the approach as seen in the wild is to assume a "pending" follow state. The problem is that if the flow doesn't follow that happy path (instant-accept or pending), then you don't know there is a problem.
Furthermore it seems that there are no existing recommendations regarding handling of a Follow to an Actor who believes you are already following them. Do you send back an Accept? Ignore the activity?
https://wiki.trwnh.com/tech/spec/activitypub/follow/
In short: sending an Accept (or Reject) is, or ought to be, a courtesy to let someone know that their Follow request was successful. In a pure subscription / peer-to-peer delivery situation, this would be the case. However, there is one big issue with this -- the existence of sharedInbox. Delivery to the followers collection specifically via sharedInbox means that the receiving server MUST be aware of who is included in that followers collection. This turns the Accept from a mere courtesy signal into an important state-synchronization message. And consequently, state may become desynced for any of a large variety of reasons. So if you get a Follow from someone who is already following you, it probably means that their state got desynced, and you should send an Accept Follow to "remind" them.
There's a tangential point about "missing id" or even "unexpected id": namely, the ID of the Follow activity often doesn't matter, as the "shape" of the activity is more important in actually processing it. Some implementations pass around partial reconstructions of this activity by its shape.
I'm not sure if this rises to the level of needing a FEP, but I can see a FEP being needed for more advanced follower collection manipulation like removing a follower, which, again, ought to be something you can just do and otherwise send a courtesy notice that you did so... but because of sharedInbox, it suddenly becomes critically important to understand such messages. See also: https://github.com/misskey-dev/misskey/issues/11015 and https://github.com/w3c/activitypub/issues/384 as it pertains to id-less Follow activities within Accept or Reject.
-
Clarification re: Inbox Forwardingjulian: If the activity is the thing being forwarded, then an additional complication could arise in that I cannot simply re-sign the activity, as my instance key does not belong to the originating actor. this is indeed an issue that arises due to the following: ActivityPub does not specify any authentication/verification mechanism HTTP Signatures, which the current fediverse uses, are not replayable or relayable. If you're concluding that this makes inbox forwarding impossible with HTTP Signatures, then congratulations, you understand why LD Signatures ended up being used for this (and why FEP-8b32 proposes using Data Integrity Proofs at the LD level as well). It's either that, or find a way to replay entire HTTP messages (so that the HTTP Signature can be validated against the original HTTP interaction). Or otherwise rethink the fundamentals of the fediverse's entire security model. -
Clarification re: Inbox Forwardingthe "object being forwarded" in this case is the activity. the language is indeed ambiguous. it should say "the original activity being forwarded". the goal of the language there is to prevent new recipients from being picked up during the recursive processing of other metadata fields -- for example, you may institute a policy that incoming activities to be forwarded must be relevant to some local object, and so you check inReplyTo, etc. but you MUST NOT add inReplyTo.attributedTo if they were initially omitted from delivery addressing. you must only check that they are a local user (or whatever your check is). EDIT: https://github.com/w3c/activitypub/issues/441