Posts
-
Article vs. Note (redux!) — summary of current implementationsjulian: Mike (upthread) suggested a compromise: that as:Note be reserved for content with attachments (images or otherwise), perhaps with a limited subset of html and as:Article be used for content with a richer set of html (e.g. tables), and including the ability to display inline images I explicitly did not specify that Note was for shorter content and Article for longer, because there exist plenty of examples of the reverse. Does anybody see potential complications from such an arrangement? I think the distinction that makes sense to me is still "do you intend for this to be formally published or not". Length and formatting are red herrings. The entire Note vs Article "distinction" is literally just "tweet vs blog post" in how it came about. From the perspective of a service like Twitter or Facebook, the Note indicates it's a "status update" whereas the Article indicates it should be shown/presented in their article publishing feature (which Twitter ironically called Notes). Consider this litmus test: if viewing the object at a permalink, does it make sense on its own, or do you need more context? If you need more context, it's probably a Note. If it makes sense on its own, it's probably an Article. (Note that this doesn't prevent Articles from having a context property.) -
How do you use `context` (if at all)?One thing to mention about context is that there are a few somewhat open questions about its usage: Does it contain objects or activities? If it contains activities, does it contain Creates or also other activities (Like, Announce, etc)? What is the ordering? These kinds of questions are rather freeform because it's somewhat up to implementers to make a decision about that. I personally think it should be just the objects, as I'm not convinced it's particularly important to have a complete backfilled view of every single like and share, or being able to construct an edit log with every single Create/Update. From the point of view of a casual consumer, that information can be lazy-loaded through checking the likes or shares collection; an optimization would be for the producer to partially embed a representation of those collections with a totalItems and maybe the first page, in order to support a "x, y, and 8 others liked this post" type of UX. But this is a matter of preference; "object or activity" is a longer-standing philosophical debate, as much as is "what makes a conversation". For the maintainer of a context, it might make sense to say "be prepared to support heterogeneous collections of both objects and activities", as the sender might attach the context to the object, the activity, or both. In theory, if you receive a Create Note with context attached to both, you might expect that both of them will be contained in the (implicit) grouping. But for maintaining an explicit collection, you kind of get to choose how to go about that. Again, I'm a little wary of placing mandates and restrictions on this, in fear of getting it "wrong* and shutting the door on some implementers. I also think the ordering should be forward chronological instead of reverse chronological, but this is part of a larger issue with collections ordering and paging: https://socialhub.activitypub.rocks/t/stricter-specifications-for-pagination-of-collections-and-orderedcollections/2633 (btw, the assertion that "every OrderedCollection MUST be reverse chronological" has been somewhat recently clarified/relaxed to only the ones introduced in activitypub as OrderedCollection) -- the ideal would be to be able to, as a consumer, request the collection with parameters for ordering, page size, and start index. But failing that, we could just fall back to a similar requirement of reverse chronology... although I dislike and hesitate to enforce this as a MUST. (The ship may have already sailed for this, but I likewise wish/think that the activitypub OrderedCollections were forward chronological instead of reverse chronological. there's something conceptually backwards about the whole thing.) -
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 -
Topics in the #threadiversesynthesis time i think the use of audience is basically "here's everybody that can/should see this in a feed". whereas to and cc are for notification policies (with to being intended to actively generate a notification). delivery happens for all of them, but after delivery, the consuming application needs to reconstruct possible intentions. BUT this doesn't chime with the current usage by mastodon et al. with mastodon, audience is generally ignored, only to and cc are considered, and notifications are instead determined by the presence of a Mention in the tag array. (which imo shouldn't generate a notification at all? you should be able to mention someone passively if desired.) so we have the intended ideal of audience being used for delivering to, well, audience... and to/cc for generating active/passive notifications. but instead, we have a situation where to/cc are used for delivering to an audience, and Mention tags are used for generating notifications (and audience is ignored). If we want to have a compatible migration path forward, then for now: to should include anyone you want to notify cc should include everyone else you want to deliver to audience should include the sum total of both of these? (but if you want to support bto/bcc, then it realistically needs to be a private Collection) alternatively, audience should include any actors whose feeds / activity-streams should include this activity/object. (this still works out in practice to anyone mentioned, plus your followers, plus probably as:Public -- which is likely the union of to and cc anyway) sample object/activity targeting for a basic (read: microblogging) use case: content: "So here's what I have to say..." inReplyTo: - attributedTo: content: "I said something." to: [] # this should be interpreted as notifying john cc: [as:Public, ] # this is interpreted as an "unlisted" post in mastodon parlance, and is necessary for delivery to mastodon currently audience: [, as:Public, ] # this is interpreted as showing in john's home timeline, as well as your follower's home timelines, and also being accessible to anyone without authentication so maybe the use of audience can address mastodon's fears of showing "group" posts in home timelines? i know this is a big concern that mastodon brought up with their current groups PR, they very explicitly do not want group posts showing up in home timelines... perhaps some heuristic can be designed so that newer versions of mastodon can filter out posts from home timelines if someone is not included in audience? sample object/activity targeting for a more complex (read: forum/discussion) use case: content: "synthesis time. i think the use of audience..." context: cc: [as:Public, ] audience: [as:Public, , , ] in this case because are not in audience, an updated/newer mastodon et al can know not to display this post in my followers' home feeds. there's still the sticking issue for mastodon in how they can get older, non-updated mastodon servers to drop the post, although i really think this is foolish, personally... you could still do it by using only audience and then older mastodon will drop the activity because it doesn’t understand the recipients. -
Topics in the #threadiversetrwnh: i’ll do some archaeology on the subject so we can see if there’s any historical evidence towards any particular usage or not. So here's some interesting things i found...what is an "audience" generally
https://github.com/w3c/activitystreams/issues/18 wrt "primary and secondary audience" as established by to/cc/bto/bcc: elf-pavlik: what we consider an audience? other people, groups, circles, lists of contacts ... jasnell: Any of these. This is intentionally left open.audience used to be scope
https://github.com/w3c/activitystreams/issues/300 The scope indicates that the audience for the note is only members of the Organization. The to indicates specific people who should be actively notified. The context indicates a larger context within which the note exists. so at the very least we can surmise the following points: "to" should actively notify specific actors implying that "cc" should passively notify specific actors? or not notify them, just deliver to them? "context" is as we already understand it, a purposeful grouping within which the object exists "scope" (later "audience") is some kind of indication of something To be clear: scope is not access control... it is closely related to to/bto/cc/bcc in that a consuming implementation can use it to determine who it ought to display the content to. So, for instance, given the note example above, a consuming implementation may include the note on the activity timeline of anyone associated with the 'My Employer' organization, but it would only activity notify two individuals listed by the to property. The context property, on the other hand, has absolutely nothing to do with audience targeting. The above note is essentially saying, "This is a note that was created in relation to A Project. Make the note available to anyone in the My Employer organization but specifically notify John and Sally" scope is advisory as to the publishers intent of whose attention they want to draw to the object. A consuming application may use the scope/to/bto/cc/bcc to determine it's access control policy if it wishes, but is not required to do so. In the example, a consuming provider could still choose to allow anyone to see the note, but only actively include the note on the activity streams of people in the company. scope could be renamed to audience https://github.com/w3c/activitystreams/issues/238#issuecomment-153408442 In the AS2 vocabulary, there is a scope property that is used generally to identify the audience. The targeting properties to, bto, cc and bcc indicate the audience subsets within that identified scope. The context is really intended to allow objects and activities to be logically grouped. For instance, in an enterprise setting, the context may group activities by project while the scope would identify one or more teams for which the activity is considered relevant, while the to/cc fields are used to indicate specific individuals to notify. gonna emphasize this bit here: The targeting properties to, bto, cc and bcc indicate the audience subsets and also advisory as to the publishers intent of whose attention they want to draw to the object a consuming implementation may include the note on the activity timeline of anyone associated with the 'My Employer' organization, but it would only activity notify two individuals listed by the to property. only actively include the note on the activity streams of people in the company. -
Topics in the #threadiverseangus: I would firstly direct you to the text of 1b12, which is the primary thing we’re talking about here. Audience property In order to render content in a forum, it is necessary to know which particular forum the content belongs to. well, if we're talking primarily about 1b12 then sure, that is what it says. it's an assertion i don't particularly agree with, and it's an assertion that doesn't particularly feel like it fully applies, either. namely: angus: 1b12 is not a bible. It is a good description of the approach we’ve decided to take to deal with group federation, but it was never going to be the last word on the subject, particularly as it was written prior to platforms like Discourse, NodeBB, Wordpress etc starting to federate in this way. the main point of contention / topic of discussion as i see it is still the audience property and when/why it should be used, and especially as opposed to using to/cc. at least for lemmy's use-case, they decided to adopt audience as a "shortcut" to point to the community actor, so that they didn't have to iterate through multiple entries in to/cc. (this is the part where i say that this isn't really in keeping with the AS2 definition or the AP delivery mechanism.) but again: angus: we should flesh out the thinking here a bit more and see if we can land in a place that warrants clear definition. the definition is indeed not clear to me either, at least not how 1b12 uses it ("belongs to"?) or intends it. i can only point to what came up in the earlier discussions when this stuff was being written. i specifically suggested at one point that audience could include as:Public but this was rejected as a suggestion because it would defeat the purpose of avoiding iterating over the property. the thing that i keep coming back to is that it is not entirely clear what the difference between to/cc and audience is or should be, in an ideal sense of "represent[ing] reality as it is", as you put it. from an AP perspective, all three will trigger delivery. from an AS2 perspective, it's got something vaguely to do with scoping" and "relevant". this doesn't sound the same as the "belongs to" language that 1b12 uses. conventionally, you could just as easily copy the to/cc just as you could copy the audience. i'll do some archaeology on the subject so we can see if there's any historical evidence towards any particular usage or not. -
Topics in the #threadiverseangus: from a purposive perspective 1b12 “reintroduces” the audience properly as it were, noting that it is underused and could suit this type of federation (i.e a group federating content on behalf of other actors) I recall in conversation around the time that 1b12 was first being written that the use of audience was motivated by not wanting to iterate through to/cc to find a Group actor. so the point very much seems to be to indicate the Lemmy community that you posted the activity to, but not using to. (i don't particularly agree with this usage, but that's how it was presented.) angus: I think it’s useful to think about the ways in which the activity of an actor “belongs to” a, or multiple, Group actors in the sense discussed in 1b12 and in the sense implied by the audience property itself well, audience has nothing to do with "belongs to", really. https://www.w3.org/TR/activitystreams-vocabulary/#h-audience-and-context indicates that activities can be "scoped to a particular audience using the audience property" -- the definition of which is "one or more entities that represent the total population of entities for which the object can considered to be relevant", as given in https://www.w3.org/TR/activitystreams-vocabulary/#dfn-audience specifically. now, that's a poorly-worded definition (grammatically speaking), but "can [be] considered to be relevant" is the operative part of it. in activitypub, due to the way that audience works for delivery, it makes for a useful mechanism for "keep these people in the loop" if you copy the audience over to your own activity. and if audience is a collection, you can make use of inbox forwarding to especially keep bto and bcc recipients in the loop. given all this, the use of audience that makes sense to me is something like this: id: actor: type: Create object: context: to: cc: bto: bcc: audience: where is a (private) Collection that includes C and D. another way you can look at it is through the lens of FEP-7888. i don't know if i worded this fully clearly (and i might have to go back and revise the wording), but the intent of audience in that FEP is to "scope to a relevant audience" by "keeping the audience in the loop" (copying context.audience to your own activity). the following example is a bit contrived but technically valid: id: type: OrderedCollection inbox: followers: audience: [<1>,<2>,<3>,...,<100>] attributedTo: id: actor: type: Create object: to: [, ] audience: [<1>,<2>,<3>,...,<100>] in general you wouldn't want to do this, however. it's easier to have a collection representing the sum total audience, rather than just relying on a JSON-LD set/array. angus: given that 1b12 is itself relatively “new” (in a standards sense) I feel that there is still scope to “flesh out” the way the audience property can work in this approach, particularly as we start to apply 1b12 to new cases like those of NodeBB, Discourse and Wordpress. the problem with that is that 1b12 is already FINAL status and can't be updated. with that said, i am wondering if the use of audience deserves its own FEP or whether it's enough to be "part of" other FEPs like 1b12 and 7888. angus: part of why I think listing multiple follower lists in the audience may make some sense is because the audience affects inbox forwarding. If other platforms are to forward the activity correctly they should know what its full audience is. In the case of multiple taxonomies that audience includes the followers of each taxonomy. i agree with you here, and that is also the intent of how 7888 uses audience. the current general "template" for interaction is like so: id: actor: type: Create object: - id: context: $(context) to: $(context.attributedTo) + $(context.followers if context has followers) audience: $(context.audience) there's some flexibility on whether it is good practice to instead rely on the audience-copying behavior and just stuff the context.followers into audience, and there's also some debate about whether cc would be more appropriate. i haven't really fully thought about that yet. julian: the limitation of a context to a single audience is mostly artificial (and not a technical one) depending on software. At least with ours, it is mainly to satisfy existing user expectations. A context could easily be a member of multiple audiences should the need arise. more or less, yeah. -
Topics in the #threadiversejulian: your logic only really needs to validate that it has an inbox and an outbox (confirmation on that would be great), and be resolvable via WebFinger. yeah, that's correct. and technically the webfinger is optional (well, we're getting there, anyway). julian: While tags can be followed natively, I'm not sure how easily it would be to manage that since each tag would need its own webfinger handle. e.g. what happens to a tag that is named the same as a user? there would indeed be a username conflict. you have a couple of options: pick a unique username at time of creation (e.g. tag.hashtagname instead of hashtagname) use the actual id for tags and don't use webfinger (in which case, they will not be followable via mastodon at present time, but may be in the future?) or... julian: Lemmy prefixes each community handle with an exclamation mark. I presume that means ! is not a valid character for usernames, at least the first character. this is actually not part of webfinger. what lemmy does is actually they allow conflicts. when you resolve acct:[email protected] you get multiple self-links and they lead to different actor ids. lemmy differentiates them with a weird hack by specifying in properties a property of https://www.w3.org/ns/activitystreams#type and a value of either Person or Group: https://lemmy.world/.well-known/webfinger?resource=acct:[email protected] i can't recommend doing the same, as this is at best a very confusing way of doing things. there is no property as:type, as type is just an alias for @type. also, if anything should be a uri, it should be the values of https://www.w3.org/ns/activitystreams#Person and https://www.w3.org/ns/activitystreams#Group, not Person and Group. and furthermore, there is nothing inherent to the type that implies the handling that they receive -- that's not what "Person" and "Group" mean. one alternative is to use a prefix property instead, and have its value be @ or !. this is somewhat better but still not ideal, because it relies on an otherwise-undefined convention that all relevant projects have to agree upon (and support for "bangtags" is not universal). but at least it doesn't rely on abusing the type declaration, i guess? there is a tangential point here in that it is hard to reify exactly what is meant by @, !, # as these are just microsyntaxes and in fact have no semantic meaning -- they're all just signals that some link should be created when parsing plain text input. you could just as easily use + instead of @ (as google+ did), or @ instead of #, or so on. you could have entirely different interpretations where @ is a "public mention" and ! is a "private mention". or that some symbol is interpreted as to, and some other symbol is interpreted as cc. angus: The “audience” of both the announce and the activity it’s wrapping should include all relevant audiences the activity was published to, i.e. the followers of the various associated taxonomies (it can be a list). Now that I say this, I’m not sure the Discourse plugin is doing 4 properly yet, but that seems to me to be the right approach. Curious on others’ thoughts. *edit, yeah 4 is not currently the case in the Discourse plugin. We just select the first taxonomic actor from the list of applicable taxonomic actors (preferencing tags over categories), but I don’t think that’s the “right” approach. Curious on others’ thoughts on 4. this sounds like it won't work nicely with 1b12 as 1b12 seems to assume a single Group actor in audience. so putting multiple values in there might not violate the letter of the FEP, but it seemingly violates the spirit of it. my personal opinion is that there is a deeper categorical error being made by assuming that some actor must be a Group, but that's besides the point for now. either you generate one activity per 1b12 actor (contrary to your point 1), or you generate one activity period (which gets forwarded to other, "non-primary" actors who don't own the thread per se, they just Announce the thread or whatever -- there's wiggle room for determining the exact protocol here by which these "downstream actors" make their followers aware of new threads that aren't managed by them. the debate is largely between Add and Announce, of course.) -
Minutes from 2 May 2024 WG MeetingYeah, id helps. it actually wouldn’t be practically possible without ids. -
Minutes from 2 May 2024 WG MeetingYup! You can wrap that onion as big as you'd like. Nothing stopping you except for convention. It's like how people on Twitter will sometimes quote tweet each other in a really long chain. -
Traversing the reply chain when working with topicsi meant the latter but you could probably do the former if there were a mechanism to link together equivalent contexts as aliases of each other. for now, the easiest thing to do would be to just copy the "authoritative" one by whoever created the thread. -
Traversing the reply chain when working with topicsthe assumption is that a context/topic is owned by only one server, but it is possible to e.g. use alsoKnownAs or aliases or similar in order to assign multiple identifiers to the same collection. i realize the "peering agreement" bits are still not written down, but you can have the context collections follow each other. that way, they should stay in sync (assuming no delivery failures). -
Traversing the reply chain when working with topicsto summarize 7888 yet again (:P) you can set the same context. this is the equivalent of posting in the same topic. you can set a new context. this is the equivalent of starting a new topic. you can set no context. this is the equivalent of having no topic. the caveat is that there are some posts that have no context/topic but are still intended to be in the same context/topic. it's up to implementers to decide which heuristics they want to use for implicit inclusion. inReplyTo chains is one way. -
Traversing the reply chain when working with topicsseems reasonable enough, at least in the absence of a clear signal that posts should be grouped together (i.e. context), you end up having to handle contextless posts somewhat differently. walking up the reply chain to an arbitrary depth is one way to do that. i'm guessing at least 3, but 5 would probably work too. -
Desired UX for forums, and accompanying user storiesOK, so here's what I've got so far, I'd really appreciate if others could add onto this with their expectations. This is basically the skeleton for what used to be FEP-9988 (which I've put on hold, since it doesn't quite make sense as a FEP in its current state -- maybe later, though!). ---Glossary
forum : A central hub of discussion bound by an audience user : Someone who makes posts post : An article of discussion topic : A collection of posts grouped by a common title and/or subject category : A collection of topics grouped by a common title and/or subject ---UX for Posts (Objects, Notes, etc) (0th order Collections)
Posts can have titles
Posts can be responding to 0-n other posts
Posts should be viewed in context of the topic
Posts can be moved to other topics
---UX for Topics (Threads, Conversations, Contexts, etc) (1st Order Collections)
Topics contain posts
Topics can be split
Topics can be closed for further posts ("locked")
Topics can have a name, summary, content that is separate from the first post
Topics can be followed for new posts
Topics exist in a category
Topics can be moved between categories
---UX for Categories (Forums/Subforums, etc) (2nd Order Collections)
Categories contain topics
Categories can be followed for new topics
Categories can feature certain topics in a certain order to the top of the list of topics ("pinned")
The "pin" can have an expiry?
Categories can have parent categories and subcategories
---UX for Users
Users can be followed for posts and topics
Users can be messaged directly
-
Article vs. Note vs. Pagejulian: as:Article: Represents any kind of multi-paragraph written work. as:Note: Represents a short written work typically less than a single paragraph in length. as:Page: Represents a Web Page. these are the formal definitions, yes, but implementation practice has diverged somewhat. i think "paragraph length" is a bit of a red herring, as there are Notes with multipletags in the activitystreams/pub examples. there are also Notes with names (titles). i go into this more here: https://socialhub.activitypub.rocks/t/federating-the-content-of-posts-note-articles-and-character-limits/4087/7 julian: Mastodon only treats as:Note (and as:Question) as a first-class object and relegates anything else to a fallback handler that takes a short snippet of the content, and shows a link back to the original source, thus losing any in-app benefits (boosts, replies, etc.) Whether this is actually true or not, I do not know. https://github.com/mastodon/mastodon/blob/12ed2d793b1b4823b0df047a47677bb0667bf43d/app/lib/activitypub/activity.rb#L9 https://github.com/mastodon/mastodon/blob/65093c619fdd1b18a4cf0c288051d8c524d5f434/app/lib/activitypub/activity/create.rb#L375 julian: Lemmy, perhaps out of principle, sends out an as:Page for new generated content, and only the replies federate out as as:Note. It has unfortunately led to some assertions that Lemmy's federation is "broken", even though it is arguably not the case. to be honest i'm not sure why they do this. it's not particularly "wrong", it's just a little weird. the thing that's a bigger issue for federation is using Announce to wrap activities that ought to be forwarded. most other fediverse implementations operate at an object level, so Announce means sharing the object. Announcing activities as a substitute for proper inbox forwarding means that some implementations may interpret all of these Announces as separate "posts". This is also more of an issue when you deal with the "activity stream" directly, i.e. if you were Facebook -- there, an Announce Create Page" would be equivalent to saying in english "John reshared Sally's Create" rather than "Sally created a web page" or "John reshared Sally's web page". bringing it back to object types though, the expectation of Page is not "a submission to a link aggregating service". i would expect it to be reserved for actual web pages, like how Tumblr lets you create custom web pages in your blog theme editor. so i'd say that it breaks down more like this: Article = formally published text, like Wordpress, typically has a title and permalink (which may be used for "conversion" logic as mastodon does currently), may be read in a feed reader or syndicated to other publishers Note = informal text, like a status update or chat message or forum post or a comment in a comments section, etc. Typically viewed in context of something else (e.g. some collection of Notes, like a profile page, replies collection, context collection, or so on) Page = structured content meant to be displayed in a web browser, e.g. Neocities, or Tumblr's "custom pages". julian: that ought to change. The question is how, but this WG is not at the point where we start throwing around decrees and making up standards. What's important to me right now is what the landscape looks like right now, and why that is the case. i don't think it's "making up standards". i think it's just standards. you're not decreeing anything, you're just describing how things ought to be done. and on an ecosystem level, you get buy-in from implementers of those standards -- of which there should at least be NodeBB, Discourse, and Flarum, right? the process of standards alignment can be slow and painful, but it should be done nonetheless. the landscape right now looks like what it looks like because there hasn't been any real protocol stewardship, and Mastodon emerged as a de facto steward of its own protocol. how we change that is by developing actual standards via FEP, WG, etc. -- and then advocating other implementers use those standards for better interoperability. put another way, it's a question of trust and authority. in the absence of a trusted authority, implementers will do whatever they want. part of the argument for activitypub as a standard is that it received w3c approval as an official Technical Recommendation. at worst, it's a rubber stamp by one of the highest authorities of web standards. at best, it's a foundation for sharing activity streams on the linked data web. but it takes a lot of work from implementers and alignment initiatives to make it reach that point. "if no one implements it, all you have is a spec". strategically, another part of "how we change that" is by making it easier for implementers doing the "wrong* thing to transition to doing the "right" thing. providing migration paths. maybe even sending them PRs, instead of waiting for them to do it. it's outreach.
-
Signalling "open in app" behaviour for AP contentjulian: I could theoretically override the anchor click handler to do a backend round-trip to check whether we could load the content in-app, otherwise fall back to a regular browser behaviour (a page navigation). i believe this is what mastodon does, but it's also worth mentioning fep-e232 Object Links as a way to tag a given Link with the appropriate mediaType used for content negotiation: { "@context": "https://www.w3.org/ns/activitystreams", "content": "This is an object link.
", "tag": { "type": "Link", "name": "object link", "href": "https://example.com/some-object", "mediaType": "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"" } } -
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?Yeah, pretty much. angus: I think it would be helpful to work through an example of where this particular point of intersection may become an issue. Say you encounter an actor of type Group. You Follow the actor. You can't expect it to behave in any one particular way, but it will generally behave in one of these ways: It is a "normal" publishing actor. You will receive Create Object, Announce Object, Like Object, and so on. It is a boost bot. You will receive Announce Object for any object sent to it, mentioning it, etc. It is a 1b12 actor. You will receive Announce Activity, and other activities described in 1b12. It is a Smithereen-style actor. There will be a wall property, and it will send out Add activities where the target is that wall. The Add.object will also have a target, and this will match the Add.target as per 400e. Bonus: It is a context moderator. You will receive Add activities where the target is the object.context. It may also additionally be a "normal" publishing actor. So for any given "post", it might be a Create/Add/Announce/Announce-Create. This isn't limited to Group actors, but it is most prevalent in Group actors because of the popular (erroneous) interpretation of Group as equivalent to Facebook Groups. One final thing to note is that "normal" publishing actors and context moderators may be any type, not just Group -- there is no specific type dependency for these mechanisms, as they are the intended mechanisms. angus: So, this would result in something like: You receive Note 2 (with context A, a collection) which is inReplyTo Note 1 (with context A) You receive an Update to Note 2 and it now has context B (a collection)? OR perhaps you receive an Add of Note 2 to context B? In both 2 and 3, the inReplyTo would still be to Note 1, which would still have context A. @trwnh something like that? Yup. id: type: Note attributedTo: context: content: "I'm posting in a thread" --- id: type: Note attributedTo: inReplyTo: context: content: "This post is in a different thread but still replying to the first" --- id: type: Article attributedTo: inReplyTo: name: "Some Article" summary: "In which I reply to a forum post with an entire blog post. This is not part of any context." content: "Lorem ipsum dolor sit amet...
" -
Publishing / Processing Collections of ActivitiesCollections don’t typically arrive in inboxes, yeah. It’s a Mastodon implementation quirk that they wire up their inbox handlers to their collection handler, to minimize the possible code paths. The collection handler is also the first step when fetching an object. This is done because Mastodon supports the ‘featured’ collection as a way to signal “pinned posts”, and they cache the first page of pinned posts when discovering a profile. This has come up in various topics tangentially over the years and hasn’t had its own thread, but basically, the assumption being made is that each activity represents a single action. You don’t typically see multiple activity types, multiple objects, or entire collections of activities being posted… and that last one is technically a spec violation too (although it only violates ActivityPub, not LDN). Part of the issue is that it’s unclear how to handle partial failures. For example, say you have multiple objects to a Create, and 7 of them are successful but 3 of them are discarded due to parsing issues. Was the Create activity successful? Or if you willfully violate AP and POST a Collection of Activities… you may have a similar “partial failure” to deal with. Now, it’s still possible to work around these concerns. But it requires careful thought and broader spec revision and implementer buy-in. The “safe” thing to do for now is to only ever have one object per activity per POST.