julian:

that's neither here nor there, it's a frontend UX thing and shouldn't really have any bearing on an AP S2S implementation detail

It has bearing on anyone browsing the linked data, as brought up immediately after:

trwnh:

also: these are “defaults”, and ultimately we should probably move toward explicitly signaling how collections might be ordered or sorted, as well as providing a mechanism for requesting non-default presentations like “show me this thread in reverse chronological order” (?reversed=true or ?sort=newest or whatever) or “show me posts starting at index 69 and containing 7 items” (?startIndex=69&window=7). to that end, i recently submitted fep/fep/1985/fep-1985.md at main - fediverse/fep - Codeberg.org for declaring an OrderedCollection to have an explicit orderType of ForwardChronological or ReverseChronological. i also have a pre-draft of a FEP dealing with collections that are not just ordered sets, but specifically sorted sets. this would define SortedCollection as an extension of OrderedCollection, as well as defining a sortedBy property pointing to a vocab term, plus a sortType of either Ascending or Descending. there’s Pre-FEP: Evolving OrderedCollection to be more useful as the thread exploring this.

Basically, imagine using https://browser.pub (or any other Web browser, really). The representation you serve in response to any GET request should be usable without requiring additional processing. You should be able to follow links normally like any other browser. This is the foundation of linked data.

julian:

They establish a conversational context for a given object

from my understanding, only 7888 and 171b do this. 76ea instead tries to establish a central view of a reply tree, which is not the same as a conversation. there are several cases where replies and context diverge:

• replying to something in a different conversation (for example, when conversations get forked or posts get moved to a new conversation)
• participating in a conversation without replying
• replying without participating in a conversation

also, there is the consideration that context is used for grouping, even if it's not resolvable. so it gracefully falls back to basic grouping behavior in the simplest case. thr:thread doesn't do this.

julian:

They federate out an Add on collection addition. (76ea also sends Remove)

you can send a Remove in all three FEPs, it might just not be called out explicitly. the use of Add/Remove is a courtesy to anyone else following along, so they don't have to fetch the collection manually every single time. (although fetching the collection every single time is inefficient, it is the only way to have a guaranteed consistent state, so there are reasons why you may want to browse the collection "at the authoritative origin", so to speak.)

julian:

171b specifies a new object type Context

i am not strictly opposed to this, but neither do i support it. it might end up being useful to define a type that means "this specifically represents a collection whose items share the same context property" (as i thinkContext is trying to do), but this should not be required.

similarly, we could define a type that means "this specifically represents a collection whose items all have content" (we could call it Conversation or CollectionOfPosts or CollectionOfContentfulObjects or whatever) but this is similarly something that shouldn't be required.

the reason that i think such types shouldn't be required is that not only are they not necessary for the basic mechanisms to work, they also might be misleading or incorrect, because ultimately the contents of any collection are solely decided by whoever owns the collection. i could declare that a collection is a Context and then immediately after this i go and Add a bunch of objects that don't have that context, or any context at all for that matter. this is something that is going to be very relevant in the interim where NodeBB and similar implementations continue to have behavior for traversing reply trees and attaching posts to topics that aren't explicitly declared as context. (not that i think this behavior is necessarily always correct, either -- it's just something that could be done, and is probably useful to do, insofar as other implementations continue to remain unaware of context and its grouping properties. you could just as equally convert posts with inReplyTo but no context into NodeBB Chat Messages instead of NodeBB Topic Posts... but this is an implementation decision.)

julian:

Collection items:

• 7888 sends objects in chronological order
• 171b sends activities in chronological order
• 76ea sends objects in reverse chronological order

7888 is agnostic as to what the exact contents are, aside from them ideally all sharing the same context -- you could have a 7888 collection contain any type in any order. however, with that said: i favor post objects (anything that has content) in forward chronological order, because this is what is most useful to the casual browser. i don't know of any forum software that chooses to present threads in reverse order with the newest posts at the top. they usually do this for topics, but not for posts.

also: these are "defaults", and ultimately we should probably move toward explicitly signaling how collections might be ordered or sorted, as well as providing a mechanism for requesting non-default presentations like "show me this thread in reverse chronological order" (?reversed=true or ?sort=newest or whatever) or "show me posts starting at index 69 and containing 7 items" (?startIndex=69&window=7). to that end, i recently submitted https://w3id.org/fep/1985 for declaring an OrderedCollection to have an explicit orderType of ForwardChronological or ReverseChronological. i also have a pre-draft of a FEP dealing with collections that are not just ordered sets, but specifically sorted sets. this would define SortedCollection as an extension of OrderedCollection, as well as defining a sortedBy property pointing to a vocab term, plus a sortType of either Ascending or Descending. there's https://socialhub.activitypub.rocks/t/pre-fep-evolving-orderedcollection-to-be-more-useful/4608 as the thread exploring this.

regarding the signaling of any given collection or actor following a specific protocol, i think we should define that explicit protocol before defining types. my old draft of FEP-9988 for "Federated Forums" was put on hold for exactly this reason -- there are simply too many protocol considerations that need to happen first. https://socialhub.activitypub.rocks/t/desired-ux-for-forums-and-accompanying-user-stories/4181 or https://community.nodebb.org/post/99491 exists as a thread to collect user stories for forum UX that should directly inform the development of such a protocol.

julian:

some degree of lossiness is unavoidable.

some degree of subjectivity is also unavoidable. this is why i was talking about the additional signals/types above, so that you can tell if a collection contains "posts" or if it also contains some additional "non-posts". i don't think everyone is going to agree 100% one way or the other on what exactly makes up a "conversation".

julian:

Sure, I'd miss some of the activities around it, so that's a concern, but it's not a dealbreaker. That's why I'm on the fence about this one.

You'd be missing activities regardless. If someone sends a Create Note with a context to the context manager, and I'm following the context and receive this activity, I might send a Like to the author of the Note but NOT to the context manager. In that case, the only way to obtain a complete view of the likes collection for that Note is to ask its authoritative origin. This is going to be something that happens a lot due to the messiness of fediverse implementations -- you might have 3 Likes be delivered directly to the context manager, but 7 other Likes be delivered only to the author of the liked post. If you are only processing the context collection, then does the post in question have 3 likes, or 10?

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

i am in favor of having contexts contain "post" objects as you well know, and for making collections into actors that can be followed and can have outboxes. you're not outdated or mistaken there

the only missing bit is some signal to describe what a context collection contains, and if it is a collection-actor, then some signal to describe how it behaves.

specifically this where the new types could come in. very loosely i was toying with something like the following

for collections representing a conversation, we have the following attributes we could signal:

• "this collection contains objects sharing the same context"
• "this collection contains objects that have text content"

for actors representing a topic or community, we have the following behaviors we could signal:

• "this actor announces any activity sent to it" (new style boost bots like 1b12)
• "this actor announces the object of any Create sent to it" (old style boost bots like guppe)
• "this actor adds any Create.object or activity it encounters with the same context to a context collection that it owns" (context manager)

maybe types aren't the best way to signal all of these things, but it's what we have available to us at the moment, barring the development of some kind of FEP to allow actors to signal which clients they have attached to them and how those clients behave.

at the very least, the collection subtypes make enough sense to consider for now... i might have to revisit the actor behaviors later, because if we just define types for every behavior then this could quickly lead to actors having more types than you know what to do with. also i think more precisely these behaviors are properties of the client attached to the actor, not the actor itself.

tldr if you want to distribute Likes and Dislikes and Announces as part of a context/conversation then i think the best we can do right now is have the author of the Like/Dislike/Announce consider putting context on those activities, and then it'd be up to the receiving context manager to decide whether they want to allow those contentless activities to be added to the context collection or not.

disagree that context should contain likes and dislikes. i think those should go in collections like likes or an extension-defined dislikes.

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 have content) 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"

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

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

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

julian:

Are there any established best practices, or am I destined to lose all of my followers?

Probably the latter, as this is a Hard Problem. I think the “state of the art” is to have a long-lived domain name which redirects to the current location — see also the PURL concept. Bluesky/ATProto gets around this by having a centralized nameserver, the “placeholder server” that assigns and resolves did:placeholder DIDs. Essentially you will need some stable authority for naming things.

If "pending" is something you feel uneasy with, would it be better to look at it as "approved" or "verified" once you get the Add? The idea is that in some future where more implementations do this, it can become a policy decision whether to show "unverified" posts. In the meantime, you can show a checkmark or other icon to indicate it's been stamped by the authority.

julian:

although I have concerns about how to handle that "local cache" situation where replies sent to a remote context aren't considered part of the context until an Add is received

If you haven't received an Add yet, then either:

• there was a network failure, and you might receive it later, or you can manually fetch the collection later to synchronize state.
• more likely: your post wasn't "approved" by the moderator of that collection, and it is intended that others won't see it, unless you send it to your followers/etc as well. consider it in a pending state.

julian:

1. • Short of that it's easier to just maintain your own context and canonical URL. That's this line in 7888:
   • You MAY set your own context, if you wish for your object to be in a separate context owned by you.

cc @[email protected]

I might have not phrased that clearly enough -- there is a soft assumption in 7888 that there is only one context set, especially when reading those bullet points. In other words, you would be overwriting the one context with another. This is the same as "starting a new thread" or "forking the topic".

At the same time, it should be possible for context collections to have multiple identifiers -- id being "canonical" and aliases being present in alsoKnownAs. I feel like having multiple collections for the same topic is not a good way forward; it's better to look at it as a state synchronization problem instead, with one collection at the origin being the source of truth. You maintain a local cache of that collection.

Sounds reasonable to me

I might not be communicating clearly either, but it’s a consistency thing. The intended usage I’m advocating for is to “make it an actor” by giving it an inbox and outbox, but also to go further and make self-managing collections that are attributed to themselves and Add objects into themselves. You can make the outbox private but you probably don’t want to. I don’t really see why to leave it out unless you were really adamant that the collections wouldn’t be actors. And if you go as far as I’m proposing with self-managing collections, then those are more clearly actors because they will be the actor of the Add activity. But also, you don’t have to go that far to just stick an outbox on it.

Outbox is required by the spec so it's a good idea not to leave it out. However, the other reason is that I would propose the outbox contain the Add activities while the items/orderedItems contains the objects. This way you have mechanisms to fetch/backfill either objects or activities depending on what you want. I agree that it doesn't make much sense to have it be private, but some implementers have made it private before, and some other implementers might check for it as a validation.

silverpill:

they don’t directly create the outbox “object”. The outbox object is managed by the server.I’m arguing that all collections work like this

I would argue that only "special collections" work like this. You can Create a Collection and manage it manually with C2S. You don't need to sign it after every change. Just sign the activities and/or objects within.

stevebate:

One could view a Collection with an inbox and no outbox as an LDN Receiver rather than an AP Actor

I think the outbox should be there even if private, and I think it should also have a followers collection even if private. I don't think an inbox alone is "enough" to send a Follow, yeah.

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

silverpill:

Yes, Collection can represent a conversation or a photo album, but I don’t think it should be used like that.

Why not? I would think that the Collection being a target for Add and Remove activities is self-evidently a natural way of doing things.

A Group with a context collection doesn't make sense at all. It implies that the Group is part of that collection, instead of the collection containing posts.

bumblefudge:

I think a Collection could have an inbox, without becoming an Actor

That's a distinction without a difference.

bumblefudge:

I’m worried our fear of neologism is leading us to cram disparate things into the same data model to avoid writing a FEP with an @Context extension-- maybe Groups and Collections both deserve to exist for different use-cases!

I’m worried of the inverse, that we throw away what was perfectly well-intended in favor of something else that works pretty much exactly the same. Collections can have inboxes and followers and they can even be self-managing actors that Add objects into themselves. All of these and more are valid mechanisms. You can have a [Collection], a [Application, Collection], a [Conversation, Service, Collection], whatever. Creating your own vocabulary term ought to be reserved for when you have a clear concept that isn't expressible using current vocabulary.

I should probably also mention I am currently workshopping a FEP for further specifying Collection subtypes, such as Conversation and MediaAlbum. Mike Macgirvin from Streams a while ago expressed a desire to identify the purpose of a context collection, and it is a perfectly reasonable ask.