FEP draft

[oneiros]

This is a first draft of how we could approach federating Starter Packs. Huge parts are closely modeled after our quote posts FEP.

The following are additional remarks I would like to point out, some giving a bit more background and some highlighting areas with open questions.

Prior art

Starter Packs were of course pioneered by Bluesky. So we had a look at that, but there were also some initiatives last year to bring them to the fediverse.

We specifically looked at this issue on Github that includes a great discussion about how to represent Starter Packs in ActivityStreams.

We also looked at Fedidevs, a service that picked up those ideas to offer Starter Packs as a dedicated service outside of existing fediverse software.

Goals

• Build on the existing discussions about representation and only change what we think is absolutely necessary
• Federate it (this goes beyond representation in AS: when Alice creates a Starter Pack on her server a.com then Bob should be able to see, use and interact with it on his server b.com)
• Respect consent. Not everyone wants to be included in Starter Packs and sometimes it might be necessary to remove yourself from a Starter Pack after the fact
• Make it reportable / moderatable: Starter Packs can and will be used to harass people ("List of the dumbest people on fedi"). We need to take this into account from day 1.
• The most important use-case is onboarding of new users. They face the problem of an empty timeline / feed and having Starter Packs to help them quickly find interesting accounts to follow is our number one priority.

Non-goal (for now)

• Display Starter Packs in timeline/feed

While this would be nice to have it is surprisingly hard to implement. There are questions around when is a Starter Pack actually finished (imagine someone creates one and then slowly adds users one by one) and when to insert it into feeds if you need to check consent first and so on.

We decided it is not worth tackling this initially, as it has limited value. Entries in a timeline / feed scroll by and are replaced by the latest posts quickly. That means they are easy to overlook and/or forgotten quickly.

It is much more important to us that Starter Packs can be easily found, ideally across servers.

Naming

As explained in the draft I did not name the new object type "StarterPack" because a) others have already announced they want to use a different term and b) because I envision other use cases.

Representation of Starter Packs

As I said, we looked at this existing proposal which includes many good and important ideas.

But we still decided to make some changes:

• Introduce a custom object type, as we need to introduce custom vocabulary anyway, so we thought we might as well make it more explicit / less ambiguous what this here is
• Base it on OrderedCollection. Some people spend a lot of time curating these things and the order of entries might be important to them.
• We always expect a Starter Pack to have an author, so attributedTo is mandatory.
• Allow an optional icon and an image
• Allow marking as sensitive (in case that for example the description, account descriptions or images might be problematic)
• Items have their own type (see "Modeling consent" below)

Limiting the number of entries

Arbitrary numbers of items would introduce a vector for Denial of Service. And also from a UX perspective it makes sense to limit the number of items.

Bluesky has a limit of 150 entries. I just copied that for now, but I personally believe we might get away with a much lower number. I can totally see that for example people in larger communities or organizations would love to curate lists of all members. But from a new user's perspective I think the larger the number of entries the lower the likelihood that they would hit a "Follow All" button.

I would love to read what thoughts others have on this question.

Placement in the "featured collection"

Mastodon already has a per actor "featured collection", which currently includes individual posts that are being featured.

We wanted to reuse and build on that.

But this leads to the awkward situation that we want to put FeaturedCollections into the "featured collection" which is at least a tiny bit weird 😬

Modeling consent

I mentioned this several times already: When it comes to signaling, validating and retracting consent I tried to copy as much from our quote posts FEP as possible. Months of consultation and discussion went into this. Also we recently enabled our implementation on our servers and are making our first real-world experiences with it.

It just made no sense to re-invent the wheel here, especially not in a way that is significantly different.

I tried to address the fact that (simple) implementations need not be very complex, but of course it is never trivial to implement.

[Floppy]

This is very cool, thanks for publishing it. My first thought is - could this be a FASP capability so that you could have shared pack servers? Or at least a protocol for discovering the packs, analagous to account_search? I imagine you've thought about this already, so I would love to know how you see it fitting in alongside the account discovery / recommendation / trend stuff in Fediscovery.

[nikclayton]

Some of these are discussion points, some are questions.

Where they are questions that can be answered by amending the FEP for clarity please do that, there's no need to answer separately here.

This can be used as a shared block list

A collection could just as easily be used for blocking as following.

For example, consider a collection called "AI enthusiasts". Or "Prominent (Israeli|Palestinian) Journalists" (delete as applicable).

Whether to use that as a starter pack or a block list is a decision the recipient makes, not the curator.

End-run around requiring approvals

In the description of FeaturedItem you write:

• featuredObjectType: The type of the object that is being featured

In the case that the featured object is an actor it MUST also include the following property:

• featureAuthorization: URI of the approval object (see section below for details)

What prevents someone from using this to create a shared blocklist where the featuredObjectType is e.g., Profile and use this to share actors to block? This would not require authorization. Or another featuredObjectType that can reference an actor, like Link or Mention?

A mechanism to allow users to share personal block lists of accounts that are harassing them has been asked for, particularly by BIPOC Fediverse users, for years.

Given that, I don't think the arbitrary limit of 150 entries makes sense either.

FeaturedCollection

"Representation of Featured Collections"

When describing the properties, please be explicit about the type of those properties, and link to the property definition. For example, is icon a https://www.w3.org/TR/activitystreams-vocabulary/#dfn-icon ?

No language designation

There's no property to denote the primary language of the collection (in particular, whatever language the name and summary properties are written in).

Are name and summary language-tagged (https://www.w3.org/TR/activitystreams-vocabulary/#dfn-content) ?

name property

• Is this plain text? HTML?
• Can this be multiple paragraphs?
• Can this contain custom emoji references (A collection of :mastodon: developers)?
• Can this contain hashtags (A collection all about #astronomy)?
• Can this contain references to other accounts (This is my collection inspired by @foo@example.com)
• Can this contain links (Journalists at https://404media.co)
• Is there a maximum length?

summary property

• Is this plain text? HTML?
• Can this be multiple paragraphs?
• Can this contain custom emoji references (A collection of :mastodon: developers)?
• Can this contain hashtags (A collection all about #astronomy)?
• Can this contain references to other accounts (This is my collection inspired by @foo@example.com)
• Can this contain links (Journalists at https://404media.co)
• Is there a maximum length?

attributedTo property

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attributedto allows multiple entities. Why only allow one here? Actors might want to collaborate on collections.

sensitive property

Shouldn't this be applied to the individual items in the collection? The collection's overall sensitivity could then be derived from the individual items (yes, no, mixed) and updated as items are added and removed.

icon property

As a best practice, please extend the example to include descriptions in multiple languages for accessibility.

image property

Similar considerations apply as with OpenGraph images.

Please link to those considerations, or spell them out here.

As a best practice, please extend the example to include descriptions in multiple languages for accessibility.

The first example

Please also add an example that demonstrates pagination, because of the note about pagination in the description of the orderedItems property.

Identical featuredObjectType?

All items in a collection are of type FeaturedItem. Do they also have to have the same featuredObjectType?

I.e,. could I have a collection that contained two FeaturedItem, where one is an actor and one is a hashtag?

FeaturedItem

type

A FeaturedItem MUST have the following property:

You then list two items. So that should be "properties".

canQuote property

To make a policy of never wanting to be featured explict, interactionPolicy.canQuote.automaticApproval ...

I think you mean canFeature there, not canQuote.

No note or similar property

These no mechanism for the collection's curator to note why an item is in the collection. That seems like something that would be necessary in some scenarios. The other issues about text properties (language, emojis, mentions, etc) all apply. More on this in #1 (comment).

General

Does this also work for pinning posts?

Can this also be used for representing a Mastodon user's pinned posts? Is that under consideration?

Can I nest collections?

So I can have a collection of collections curated by other people?

I.e., is this a valid item?

    {
      "id": "https://fedi.example.com/users/alice/featured/23/items/1",
      "type": "FeaturedItem",
      "featuredObject": "https://fedi.example.com/users/jennifer/featured/2",
      "featuredObjectType": "FeaturedCollection",
    },

If not, why not? I could imagine a "Good science communicators" collection that was itself a collection of the "Good astronomy communicators", "Good physics communicators", "Good maths communicators", ... collections.

If collections can be nested...

You'll need to handle the case where a collection contains itself, or contains a collection that contains itself, etc...

[grishka]

I don't like that the only piece of identifying information that the Delete for consent revocation contains is the ID of the approval stamp itself. This would mean each server would need to maintain a separate database index just for those approval stamps. The more features using this scheme are introduced over time, the more cumbersome it will become — you will either have to do a bunch of SELECTs on different tables every time you receive one, or make a dedicated table which would map the ID to the parent object type.

[nikclayton]

Similarly, when a FeaturedItem is added to a FeaturedCollection, this can also be distributed in the form of an Add activity to all followers of the user that owns the collection and all actors that are already part of the collection.

The "... all actors that are already part of the collection" text -- does that include the actor that was just added?

If not, it probably should.

Then an actor could have an automatically maintained synthetic collection that is "Collections I am a member of".

[nikclayton]

Is an actor in a collection notified if some of the collection properties change?

The FEP says they're notified if the members of the collection change (a FeaturedItem is added or removed).

What if the name or summary of the collection changes? That could be an abuse vector -- create a collection with an innocuous name, wait for people to consent to be added to it, and then change the name to something considered to be harassment.

[nikclayton]

What should a server do if it receives a featured collection where the value of the totalItems property does not match the number of items in the collection?

[jfietkau]

Hi, creator of FediRoster and ActivityPub programmer for Fedidevs here. I was one of the people who received an invitation to provide feedback on an earlier internal draft of this FEP, and my concerns have more or less all been incorporated into this proposal already. Here are some general thoughts:

FEPs describing an ActivityPub schema like this have a purpose of defining syntax and semantics, with the latter shaping the former. The fundamental challenge is to define types and processes that are generally applicable and useful for services other than Mastodon too, i.e. not to unintentionally enshrine specific presentation assumptions, but also not to muddy the purpose so much that interoperability becomes fruitless. The promises I see enshrined in this current draft are:

1. The ability to provide a (finite and fully enumerated) collection of accounts (or other stuff, hashtags are mentioned) with the semantics of a follow recommendation or endorsement
2. Every account in the collection having given permission (explicitly or via a blanket setting) to be included in it, and this permission being revocable and externally verifiable, as in FEP-044f
3. Every collection having a verifiable¹ owner who is responsible for it in terms of moderation
4. Collections having an opportunity to bundle auxiliary information (title, description, icon, image) that consumers can use to decide whether they want to bulk-follow the content of the collection

¹ The current draft does not strictly fulfill verifiable ownership. As mentioned in my last comments on the internal draft, my recommendation would be to point to FEP-fe34 for verification, which tl;dr would mean that featured collections attributed to some actor would need to either be hosted on the same origin as that actor or be cryptographically signed by that actor. If neither of those are true, reject the collection as invalid.

Now, Mastodon's vision for their own implementation of “packs” (whatever they end up being called) may be more specific than that. From my understanding, Mastodon assumes that these collections will generally be fairly small, be curated by a single person, not be easily transferable (in the sense of ownership) between accounts, and be publicly hosted on their profile as a follow recommendation. It might even be – and to be clear, I'm entirely spitballing – that Mastodon's upper limit for the size of a pack could end up lower for packs created locally vs. packs received from other servers. And if a Mastodon account gets deleted, all its packs vanish with it.

Other participating platforms could set themselves apart by offering more sophisticated features, such as collaborative curation, import/export, delegation and transfer of ownership, or interesting branding for the image assets. All that is power user stuff that's likely more complicated than Mastodon will want to accommodate, and it is the very short version of my vision for Fedidevs to keep existing. 🙂 Another related project that could adopt this FEP is Mastodon Listen, a German website that maintains follow recommendation lists based on specific Wikidata queries instead of manual curation.

The main aspect that this FEP remains deliberately brief on is how these collections will be discovered and shared. It specifies the possibility to list them on an actor's profile, which I have pushed to make optional, as it is now, instead of mandatory. So currently the FEP permits the existence of “unlisted” featured collections that are, in principle, accessible directly via their URL. (I'll note that this was also one of the first requests mentioned by others in yesterday's Fediforum session about this feature.) I'm sure we could list many ways to share packs besides pinning them to the profile, such as attaching them to timeline posts or bundling them with invite codes, and my understanding is that the Mastodon team is considering all these options. They could be described here if desired, perhaps in a later revision of the FEP, or in a different FEP altogether. I happen to think that servers should give users a way to load a featured collection directly from its URI, like Mastodon already allows for most other objects it can handle, but I'm not dead-set on making that a MUST in the spec, I just think it's a generally sensible idea to allow the sharing of non-public featured collections between parties on different servers.

To summarize my stance, I think the current draft hits a happy place in between being too Mastodon-specific and too generalized to be useful. There are details that would still benefit from clarification, but I don't think the schema will need any fundamental changes.

[oneiros]

This is very cool, thanks for publishing it. My first thought is - could this be a FASP capability so that you could have shared pack servers? Or at least a protocol for discovering the packs, analagous to account_search? I imagine you've thought about this already, so I would love to know how you see it fitting in alongside the account discovery / recommendation / trend stuff in Fediscovery.

We definitely plan to add search capabilities for this in fediscovery. I hope that something very similar to account_search should not be too hard to add.

[jfietkau]

@nikclayton

For my understanding – I mainly know you as a Mastodon client developer, is that the lens you're looking at this through? Because I imagine these objects will look rather different in the Mastodon API than in ActivityPub. See also FEP-044f vs. the Mastodon quote post API for comparison.

Whether to use that as a starter pack or a block list is a decision the recipient makes, not the curator.

By using the FeaturedCollection type, the curator states that the list is a collection of follow recommendations – this does come with some implied intent. What a recipient does with that information is indeed up to them, and I am at least intrigued by the idea of a “block all” UI affordance. But generally, I don't think it makes much sense to try to shoehorn shared block lists into this specific schema. As you note, the consent to be listed makes no sense in that context, and you'd want other auxiliary information (e.g. moderation logs) attached instead. Big topic, good conversation, but is it fruitful here?

Given that, I don't think the arbitrary limit of 150 entries makes sense either.

In practical terms, implementations need some sort of limit, or you could crash two servers at once by sending one a list of 1000000 accounts to fetch from the other. I don't think there is a universal answer for what that limit should be, although as someone with fond memories of Academics on Mastodon, I definitely understand the use case for follow recommendation lists with a few hundred entries.

When describing the properties, please be explicit about the type of those properties

There's no need to reproduce the Activity Vocabulary spec in this FEP. The spec already states that FeaturedItems are Objects, the inherited properties follow from there.

Same goes for pagination, this spec builds on established types, there's no point reintroducing them.

Good questions on HTML vs. plain text and on multi-language support for name and summary! For Fedidevs, we probably won't need rich text formatting, but I am also interested in the option to include user tags in the description.

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attributedto allows multiple entities. Why only allow one here? Actors might want to collaborate on collections.

This should probably be clarified in the spec, yeah. Since one of the main purposes of the attribution is moderation, I could see a case that it should be unambiguous who to take action on if a collection turns out to be malicious. The wording in the spec “The actor responsible for this collection” is deliberate in the sense that people can collaborate on featured collections all they want (although my understanding is that Mastodon will probably not offer UI affordances for it), and collaborators can of course be listed in the description, but in the end someone will have to stick their neck out and be responsible for the result.

Can I nest collections?

I'm sure this is one of those topics that ActivityPub implementers have litigated ad nauseum, but my first response as an implementer is “oh god no”

[nikclayton]

@jfietkau

is that the lens you're looking at this through?

Only to the extent that it makes it easy to spot missing parts of the spec that will cause interoperability and accessibility issues later.

By using the FeaturedCollection type, the curator states that the list is a collection of follow recommendations

I disagree. I think "Featured" is neutral-to-very-weakly-positive, and the name and summary properties carry the detailed semantic information. Call these EndorsementCollection or FollowRecommendationCollection if that's the intent.

Big topic, good conversation, but is it fruitful here?

Given that there's a demonstrated need for shared blocklists I think it's likely the wider developer community will look at this and start thinking about creative ways to use this to implement shared blocklists (https://en.wikipedia.org/wiki/Desire_path).

With that I think it's prudent to take some time to view the proposal through that lens and consider the ramifications. Including ways that this proposal might make those safety features easier to implement.

An alternative -- for example, rewriting this proposal to restrict FeaturedItems to only be Actors to close the loophole I identified -- is, I think, likely to be interpreted as another example of anti-Black sentiment on the Fedi.

There's no need to reproduce the Activity Vocabulary spec in this FEP. The spec already states that FeaturedItems are Objects, the inherited properties follow from there.

I don't believe that's true. For example, attributedTo in the spec is "one or more entities". In the FEP it's "exactly one". That's an interoperability issue right there -- reusing property names and giving them different semantics is asking for trouble.

There's also examples in other parts of AP where spec properties are mis-used, causing interoperability issues (most recent example I've had to deal with is custom emojis). That's why I was explicit about asking if name and summary contains HTML. The spec says no and yes respectively, but if this FEP already disagrees with the spec on one property then all other bets are off.

So I think it is worth both (a) linking to the relevant properties in every FEP, and (b) cross-checking to ensure the FEP is not changing the semantics of the property.

but my first response as an implementer is “oh god no”

What's your first response as a potential user of the feature? Those are the people we should be thinking about.

[oneiros]

I don't like that the only piece of identifying information that the Delete for consent revocation contains is the ID of the approval stamp itself.

Thanks for pointing this out. This was indeed an oversight. I tried to copy as much as possible from quote posts, but that FEP included no example for a Delete activity, so I quickly came up with one without giving it enough thought.

Changed it to include the full object instead of just the id.

[nikclayton]

If I've read the FEP correctly the sequence of work to add a new Actor to a FeaturedCollection is as follows:

Aside: Sequence diagrams would be really helpful in proposals like this. If FEP-markdown is allowed to contain diagrams then mermaidjs.org is great for this.

Suppose @alice@foo wants to add @bob@bar, and @carol@baz is following @alice.

1. @alice@foo instructs her server to add @bob@bar.
2. The server foo sends a FeatureRequest to bar.
3. @bob@bar approves, and bar sends an Accept to foo.
4. foo adds a FeaturedItem for @bob@bar to the collection.
5. foo sends M+N Add activities, one to each of @alice@foo's followers (M), and one to each of the actors already in the collection (N).
6. Each server that receives the Add activity from the previous step will need to verify the FeatureAuthorization of the newly-added actor, by sending a <something> to Bob's server.

A few questions about that:

1. A FeaturedCollection is also an OrderedCollection. Do you intend that the ordering be consistent across different servers? If yes, how is that maintained? Is the published property mandatory on Add activities, and for FeaturedItem? Some other approach?

2. Worst case, at step 5 above, this recreates the thundering herd problem when Mastodon servers rush to regenerate preview images. The server for @bob@bar is going to get a rush of <something> requests. Just like we have now with preview images, a super popular account adding an account on a smaller server is essentially triggering a DDoS on the smaller server.

Is that a consideration / concern?

3. I've written <something> above because it's not clear from the FEP what the servers at step 6 are supposed to send in order to verify the FeatureAuthorization. I thought it might be a FeatureRequest, but the documentation for FeatureRequest says it should be sent by the owner of the collection, and the servers at step 6 are not the owners of the collection.

[nikclayton]

Suppose I'm @nik@example.com, and I have a collection containing @foo@mastodon.social, @bar@mastodon.social, @baz@mastodon.social.

There's a spam wave affecting the Fedi, primarily coming from spam accounts created at @mastodon.social, and the @example.com admins decide to temporarily block mastodon.social.

What happens to the three accounts from that domain in my FeaturedCollection? If I followed those accounts the follower relationship would be severed. Are they removed from the collection?

[nikclayton]

Because of the verification mechanism an actor is informed when there is a request to add them to a collection (which is not quite the same as actually adding them to the collection, per my other question).

They're not informed if they're removed from the collection, I think. Followers are informed, as are the remaining members of the collection. But the account being removed is not informed.

Is that a deliberate choice?

[HelgeKrueger]

If I've read the FEP correctly the sequence of work to add a new Actor to a FeaturedCollection is as follows:

Aside: Sequence diagrams would be really helpful in proposals like this. If FEP-markdown is allowed to contain diagrams then mermaidjs.org is great for this.

I just want to +1 this. If somebody draws one for the Add activities, showing that it leads to following servers times request to the server that approved being added? I would be very thankful. FEP-8b32 would be how to fix this.

Also FEP-markdown allows for mermaid. Use it.

[nikclayton]

A featured collection appears to be implicitly public.

For example, there doesn't appear to be a mechanism to create a featured collection where the membership of the collection is only available to the members of the collection, or only to my followers and the members of the collection, or only to me.

To put it another way, there's no mechanism to describe which group the collection is being featured to.

Is that a deliberate design decision? If so, please make it explicit in the FEP.

There's also no mechanism to express how discoverable the collection is. Is the intent that featured collections are inherently discoverable, and that consenting to membership of a featured collection overrides a user's other discoverability preferences?

[nikclayton]

What is the type of FeatureRequest.instrument?

In the spec it's Object | Link.

This suggests that the FeatureRequest can include the entire FeatureCollection object in the FeatureRequest.

Assume the sending server does include the entire FeatureCollection object.

Is the receiving server supposed to trust this, or is it supposed to fetch the most recent featured collection from the sending server, to present it to the user as part of the obtaining consent flow?

[nikclayton]

There's no mechanism in FeatureRequest for the curator to include a note explaining why they want to add the user.

Should that be added? That seems necessary as part of providing informed consent. It would also allow servers to provide FeatureRequest recipients with a more nuanced policy, e.g,. "Auto-reject all requests with no note, others require manual review".

There's a weak analogy here -- there's no mechanism, when sending a follow request, to explain why you want to follow someone either. I don't think that analogy holds, as a follow is 1:1 interaction, and exposes the followee's content to 1 new account, whereas adding an account to featured collection potentially exposes it to vastly more people.

Similarly, when rejecting a FeatureRequest there's no obvious mechanism for the requestee to include a note back to the requestor explaining why they're rejecting the request. That note might be auto-generated ("This account only reviews requests that include a note") or it might be hand-written by the requestee.

[nikclayton]

The FEP says:

Featured collections are created by individual actors. As such they SHOULD become part of the actor's featured collection.

Does this mean that FeaturedCollection.attributedTo can only ever point to the actor that is featuring the collection?

To put it another way:

Suppose @mastodonengineering@mastodon.social creates a FeaturedCollection called "Official Mastodon developers". This is a high-trust collection, it's by an official account, with a verified link to joinmastodon.org.

Can I, as someone who is interested in Mastodon development, include a reference to this collection in my actor's featured collection, properly attributed back to @mastodonengineering@mastodon.social?

If the answer to this is "no" then I think this risks several problems.

1. The potential for fake/phishy collections, designed to lend authority to the account that created them (assume all accounts in the collection are phishy sock puppets created for this purpose). Obviously, people can report them when they see them, but as we know with spam/phish waves, there's still a risk.

2. A plethora of duplicate/very similar featured collections, risking "feature fatigue" amongst people who find themselves on many collections (e.g., I can easily imagine tens of thousands of people creating a collection wanting to include Cory Doctorow).

[nikclayton]

Suppose I have a collection that features @foo@example.com, and my server receives a valid Move activity indicating that @foo@example.com is now @bar@example.com.

Does the server update the collection to reflect this? If yes, is that done "silently" (because the Move should have federated to everyone who cares, so all servers that care will perform the same silent update), or as a Remove of the old account followed by an Add of the new account? Or something else?

[nikclayton]

The most important use-case is onboarding of new users. They face the problem of an empty timeline / feed and having Starter Packs to help them quickly find interesting accounts to follow is our number one priority.

Is "This starter pack contains interesting accounts and should be recommended to users" a property of the starter pack you think should be federatable information about the pack?

If no, how are users on small servers supposed to find starter packs with accounts they might want to follow? Saying they should search is a bit chicken-and-egg.

Also, if the answer is "search" (either locally, or via fedidiscovery, per #1 (comment)), then do starter packs contain enough information to usefully rank the results, in order to meet the goal of "find interesting accounts"?

[mradcliffe]

A pure ActivityStreams implementation of starter packs would be to implement a Group actor. The Group actor's Following collection is essentially a starter pack. This would also open up the possibility of displaying a feed of actors' posts to further improve the decision making process for someone who wanted to follow actors that the Group actor follows.

This works with the already existing consent model because many implementations allow an Actor to opt-out of automatically accepting Follow requests. Mastodon also implements opt-in via discoverability http://joinmastodon.org/ns#discoverable.

Distinguishing Group actors that are Starter Packs from other types of Group actors may be difficult, but this opens the possibility of a specific software / implementation for ActivityPub that is only focused and scoped around Group actors representing Starter Packs (Following collections) of actors that want to be discovered and accept Follow requests. Software acting in bad faith could be defederated.

[nikclayton]

Ping @oneiros -- any news?

[oneiros]

Ping @oneiros -- any news?

Not really. I am still processing the feedback we got here (lots of good ideas/questions btw) and through other channels. And we are working on how we want to all of this to look and work in Mastodon, which in turn could have consequences for federation.

Hopefully I can push an update next week.

[oneiros]

Alright. First of all, thanks again for all the feedback and sorry for the long radio silence.

I just pushed a few updates, some of which reflect changes in our plans and some of which address feedback:

• Added an optional topic attribute to FeaturedCollection, which is a single hashtag. We would like to experiment with letting users (optionally!) give a single hashtag that best describes this collection / the category this collection falls into. Took this opportunity to clarify usage of hashtags in summary (allowed, should be mirrored in tag, as with Note etc.).
• Added another optional attribute discoverable. Similar to the same attribute on actors, this can be used to say whether you want your FeaturedCollection to turn up in searches / be used during onboarding. The idea is that people can create their collections and just share a link to them, but not have them turn up outside of their profile otherwise.
  As our use-case is still mostly helping users discover people to follow, we do not currently have plans for other levels of visibility. Collections are meant to be shared and thus always "public" in a way.
  I thought a bit if this should be http://joinmastodon.org/ns#discoverable, but I think defining this in the namespace of the FEP is more convenient. Please let me know if you think otherwise.
• I scrapped the idea to add FeaturedCollections to the existing featured collection. I had to explain this a couple of times now, and this is not fun. Having a new collection seems cleaner, more focused and easier to explain. (Also makes it easier to ignore for anyone not interested in this.)
• I clarified who to address activities to. I believe this is a regular source of confusion in AP and I do not believe there is the one correct answer in cases like this. So I changed this into more of a guideline, but leave room for implementations to actually come up with different (hopefully better) ways to deal with this.

There were some concerns voiced that the authorization mechanism leads to more messages being exchanged between servers (definitely true!) and that this might overwhelm smaller servers. This was a trade-off made when we designed quote posts. Those have been deployed to production and so far we have not gotten any feedback that servers suffer in any way. I do not believe the proposal here (being very closely modeled after quote posts) should be any worse in this regard. Still, I agree that this is a situation we need to keep monitoring.

FEP-8b32 was mentioned as a possible way to reduce the need for some of those requests. I agree this is probably a good idea. I also believe, we could add this to both quote posts and this here in a backwards-compatible way. This makes this doubly interesting to me, but also means we can postpone a final decision here for a while.

There were other questions, that I have not addressed yet. To some, I do not have a good answer (yet). But I believe we have enough of a foundation here, to start experimenting with implementing some of these ideas and find out what works, what does not, and what might be missing.

[silverpill]

FEP-8b32 was mentioned as a possible way to reduce the need for some of those requests. I agree this is probably a good idea. I also believe, we could add this to both quote posts and this here in a backwards-compatible way. This makes this doubly interesting to me, but also means we can postpone a final decision here for a while.

@oneiros FEP-8b32 was also proposed in mastodon/mastodon#36475.

[trwnh]

from https://github.com/mastodon/draft-feps/pull/5 there was something about migrating over old discussion points and it looks like that might have ended up not happening, so i'm going to re-review this i guess

summary of points:

• use cases could be more clear/refined. reference to "other uses" goes nowhere... i think an ActorCollection could make sense for addressing "aspects"/"circles"/"privacy lists"/"close friends"/etc?
• some "required properties" probably are SHOULD, not MUST -- you can process a collection without them so there's no real reason to hard-require them. you can get by with only id + orderedItems + attributedTo in the minimal case, and the type array should include the new class to help signal the purpose of the orderedItems
• IRIs should be called out wherever new terms are being defined
• some language could be cleaned up, typos etc
• i'm unsure of why topic exists

[trwnh]

other uses such as...?

calling them "featured collections" implies one specific use, which you call out in the first two sentences of the summary:

• users and/or objects you "would like to recommend to others" ("like to recommend", or simply "recommend"? and recommend how / in what way?)
• find interesting people and content to follow (this is more concrete)

one use i can think of for "collections of actors" in general is to then be able to use those collections for addressing, not simply "featured recommendations". this would behave as a sort of contact list and hook into the status composer, to provide the feature that diaspora* called "aspects", that google+ called "circles", that facebook called "privacy lists", that instagram called "close friends" (limiting you to 1 such collection), and that twitter briefly called "circles". however, this use case ideally needs the ability to make collections private (otherwise, other people could use them for addressing without your permission). in this case, FeaturedCollection seems like the wrong term to use for this variant. i think ActorCollection could work, although it would have problems with items that are as:Hashtag.

[trwnh]

[type] MUST be FeaturedCollection

• does this support other term mappings (debatable; you may want to require a certain term definition or context for the sake of non-LD processors)
• does this support multiple types (hint: it really should)

it is possible for these collections to belong to more than one class/set of things. requiring a single type prevents implementing multiple data models for what is fundamentally the same thing.

[oneiros]

Changed wording to "MUST include FeaturedCollection"

[trwnh]

FeaturedCollection

what is the IRI for this term? it should be mentioned here, at least in parentheses, and ideally defined in a section of this FEP (and then you can refer to the definition)

so something like:

"a new object type, FeaturedCollection (https://w3id.org/fep/xxxx/#FeaturedCollection)." (could be hash vs slash, could be in the mastodon namespace, could be ActorCollection pending the "other uses" discussion thread above...)

[oneiros]

Added in parentheses.

[trwnh]

is it really a problem to not have a summary? you can argue name is useful to require (although i would argue it is possible to continue processing even without a name), but summary being a MUST is iffy.

[oneiros]

I really believed it was necessary to have one (if I want to convince others to follow someone, I should maybe give a reason?), but I was recently asked to drop this requirement from Mastodon's code, so there is no need to have this required here anymore. Moved it to the optional section.

[trwnh]

likewise for totalItems, this is a SHOULD imo. you don't need to be told this if you can just count them yourself (Array.length or similar)

[oneiros]

OK.

[trwnh]

[icon] SHOULD be a square image

s/SHOULD/MUST. as:icon is defined as specifically being 1:1 square aspect ratio.

[oneiros]

Ah, I did not realize. Thanks, I changed the wording accordingly.

[trwnh]

Similar considerations apply as with OpenGraph images.

what are these considerations? be more explicit

[oneiros]

We discussed this before (I think in the private repo) and IIRC Julian came up with a couple of links, none of which I was comfortable including here as authoritative sources.

Happy to amend this, but I personally have a hard time coming up with a better wording. Also it might be worth pointing out that Mastodon will not use this in the initial implementation.

[trwnh]

I guess it could be fine to leave it unspecified...

[jfietkau]

Yeah, there isn't really anything good to point to. The OpenGraph spec at https://ogp.me/ says nothing of note, the general recommendations you find online (1.91:1 aspect ratio, recommended resolutions) are just something that Facebook originally came up with and that have informally evolved since then. I think “similar to link previews” is more or less the important bit, people can figure it out from there.

[trwnh]

I guess the wording I'd go with then is something like this:

* `icon` (`https://www.w3.org/ns/activitystreams#icon`): An icon that represents the collection. An `icon` can be used in list views alongside the `name`. Activity Streams 2.0 requires that the icon's representation MUST have a 1:1 square aspect ratio and be suitable for display at small sizes. Publishers SHOULD provide at most 1 icon.
* `image` (`https://www.w3.org/ns/activitystreams#image`): An image that can be shown alongside the collection, possibly as a page header or as part of a link preview. Unlike an `icon`, an image's aspect ratio and size are not constrained to be 1:1 or small. Publishers SHOULD provide at most 1 image.

I'm realizing there aren't any cardinality assumptions included in the text of the FEP, so it would be a good idea to call those out explicitly too wherever there might be any silent assumptions being made.

[trwnh]

worth emphasizing

this crosses from "emphasis" to "redundancy" imo. this paragraph could be reworked into something clearer by focusing on not just these two properties, but on the intended processing model itself. for example:

Applications publishing collectionss can omit non-required properties, so applications consuming collections should be prepared to handle some of these properties being missing. For example, icon and image are decorative in nature, and may be omitted. Depending on what makes sense in their UI design and the specific situation, consumers may wish to either show default icons or images, or otherwise display collections without these elements.

[trwnh]

discoverable

is this http://joinmastodon.org/ns#discoverable? if so, note that

[oneiros]

I do not think it is, and I updated the draft to reflect this. There are subtle differences, e.g. http://joinmastodon.org/ns#discoverable is meant to be used on an actor and has severe consequences in many different areas of search and discovery. This here is much more narrow and focused. I also suspect the exact meaning might still change a bit.

But I might be thinking too much like a programmer here and not like an ontologist?

[trwnh]

I'd say it's the other way around, actually -- you're thinking too much like an ontologist and not like a programmer :P

This complicates the term definition then, because discoverable on an actor and discoverable on a featured collection might both be used in the same document. I think your two courses of action here are either to say:

• http://joinmastodon.org/ns#discoverable is applicable to multiple types (accounts, posts, featured collections); or
• define a new term that is similar but more specific.
  • You may want to ease the burden for non-LD users by using a different shorthand term than discoverable, to more clearly signal the difference; otherwise, you would have to scope the definition to only a specific part of the document (which can be confusing to expand correctly, since it requires tracking changes to the active context for a given node).

[oneiros]

• http://joinmastodon.org/ns#discoverable is applicable to multiple types (accounts, posts, featured collections); or

OK, you convinced me.

[trwnh]

topic: A single Hashtag object that represents the main topic or category of this collection.

what's the point of this property? how does this differ from as:tag? why is it important to specify a "main" one?

[oneiros]

We will experiment with a single topic per collection in Mastodon's UI. For our purposes this must be a single hashtag and it must be totally unambiguous which one. That is why I do not think it should be buried in tag.

It is totally optional and if it turns out nobody uses or likes this, we might reconsider and remove it.

[trwnh]

one other thing: with quote stamps there was an alternative option to have a "quotes" collection on the post which would contain whatever is officially acknowledged by the author/owner of the post. this was put aside because mastodon wanted to avoid the need for a "quotes" collection for verifying individual posts/relations. (i would still argue that the presence of a "quotes" collection doesn't mean it has to be public, but that ship has kind of sailed.)

in the case of "featured collections", is there a similar concern with having a property on the actor "has been featured in these collections"? it seems like the kind of thing someone might reasonably want to promote -- "i've been added to these lists", basically.

[trwnh]

Per #1 (comment) I'm realizing there aren't any explicit mentions of assumed cardinality, so it would probably be a good idea to call out all properties that could have multiple values but are expected to have at most 1 value.

[silverpill]

Featured items in this collection are embedded and have an id property. Are consumers expected to trust these objects, or fetch them by id?

Is id required on FeaturedItem? Can FeaturedItem originate from a different server than FeaturedCollection?

[silverpill]

This sentence is not very clear. What would it mean for a property to have zero values?

[silverpill]

Providing examples of these Add and Remove activities would be helpful.

[silverpill]

I believe that actor property should also be mandatory (RFC-2119 REQUIRED?), because all activities have this property.

It is not possible to determine who sent an activity if its object is not an actor (the text previously mentioned this possibility).

Related question: can an actor request to include an object that is attributed to another actor?

[silverpill]

The actor property is missing in this example.

[silverpill]

The id property is missing in this example.

[silverpill]

Suggested change

	In both cases, `Accept` or `Reject`, the object of the activity is the `FeatureRequest`. In case of an `Accept` the activity MUST also include a `result` property pointing to a `FeatureAuthorization`.
	In both cases, `Accept` or `Reject`, the object of the activity is the `FeatureRequest`. In case of an `Accept` the activity MUST also include a `result` property pointing to a `FeatureAuthorization` object.

[silverpill]

Shouldn't this object have an attributedTo property? Are consumers expected to identify the actor who issued the authorization based on the value of interactingObject?

[silverpill]

Is FeatureAuthorization a public object (to: https://www.w3.org/ns/activitystreams#Public)?

[silverpill]

How to determine if the actor has a permission to revoke the given FeatureAuthorization?

(This is related to the previous question about attributedTo)