StarterKit Extension Documentation

Specification

Base Structure

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Collection",
  "id": "https://example.org/recommendations/category-name",
  "name": "Human Readable Name",
  "summary": "Description of these recommendations",
  "totalItems": 0,
  "items": []
}

Properties

Property	Type	Required	Description
`@context`	string	Yes	Should contain "https://www.w3.org/ns/activitystreams"
`type`	string	Yes	Must be "Collection" or "OrderedCollection"
`id`	string	Yes	Unique URI identifying the collection
`name`	string	No	Human-readable name of the collection
`summary`	string	No	Description of the collection's purpose
`totalItems`	number	Yes	Total number of items in the collection
`items`	array	Yes	Array of Person and Hashtag objects
`published`	string	No	ISO 8601 timestamp of creation
`updated`	string	No	ISO 8601 timestamp of last update

Item Types

The items array can contain two types of objects:

Person Objects

{
  "type": "Person",
  "id": "https://example.org/users/username",
  "name": "Display Name"
}

Property	Type	Required	Description
`type`	string	Yes	Must be "Person"
`id`	string	Yes	ActivityPub ID of the account
`name`	string	Yes	Display name of the account

Hashtag Objects

{
  "type": "Hashtag",
  "id": "https://example.org/tags/tagname",
  "name": "#tagname"
}

Property	Type	Required	Description
`type`	string	Yes	Must be "Hashtag"
`id`	string	Yes	URI identifying the hashtag
`name`	string	Yes	Hashtag string (must include '#' prefix)

Example Activity

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Collection",
  "id": "https://pixelfed.social/starter-kit/1",
  "name": "Photography Recommendations",
  "summary": "Recommended follows for photography enthusiasts",
  "totalItems": 4,
  "items": [
    {
      "type": "Person",
      "id": "https://example.org/users/photographer1",
      "name": "Nature Photographer"
    },
    {
      "type": "Person",
      "id": "https://other.org/users/photographer2",
      "name": "Street Photography"
    },
    {
      "type": "Hashtag",
      "id": "https://example.org/tags/photography",
      "name": "#photography"
    },
    {
      "type": "Hashtag",
      "id": "https://example.org/tags/naturephotography",
      "name": "#naturephotography"
    }
  ]
}

Hashtags should probably use the as:Hashtag object type.

Hashtags should probably use the as:Hashtag object type.

Good catch, updated!

I don't think Collection is correct at the top level here, instead it's the "follow recommendations" that are the collection.

i also don't think "auto follow" is necessarily a good idea, I'd think of these more as recommendations where you can choose to follow some of the accounts or all, ditto with following hashtags.

Finally, I don't think "auto blocking" belongs in starter kits, but in a separate system, nor account privacy/reach settings, since it'd be difficult to map this accurately across different fediverse software.

Also, the Collection can be mixed typed, i.e., one collection can include both Person/Group actors and Hashtags, it's then up to software to choose how to display the collection, whether as a simple list or as separated out by object type.

Additionally, a starter pack for the Fediverse should almost certainly recommend instances that a new person may want to join. (Gosh I wish we had an Instance/Server object type)

The current structure here of everything sorted out by Object type means that you cannot reuse the Collection pagination logic

The current structure here of everything sorted out by Object type means that you cannot reuse the Collection pagination logic

Good point, I've updated it, let me know what you think!

To further expand on this:

Finally, I don't think "auto blocking" belongs in starter kits, but in a separate system, nor account privacy/reach settings, since it'd be difficult to map this accurately across different fediverse software.

I think Starter Packs are fundamentally different to Safety Packs, the former helps you get started somewhere and follow a bunch of people. The latter is after you have an account, though may be recommended by the former.

In a Starter Pack it's a one-time type of deal, not a subscription to a list of people to follow, where as for Safety Packs, that's an ongoing and evolving need, safety doesn't just happen once, it continues to happen constantly. Special care also needs to be taken to make sure retractions happen correctly (which I think are likely beyond the Add / Remove semantics of Collections). I do think Safety Packs could be built off the ideas I put fourth in the background information for my FIRES project.

The current structure here of everything sorted out by Object type means that you cannot reuse the Collection pagination logic

Good point, I've updated it, let me know what you think!

For hashtags, I'd omit the id since hashtags occupy a global namespace, and it generally isn't possible to subscribe to a specific hashtag on a specific server at present.

For Actors, you probably also want to include some additional properties, e.g., url, preferredUsername and probably a handle (though handle needs to be defined — there was that FEP that was going from Actor to Webfinger acct, maybe that has a property to use?)

Hey Dan, good stuff, thanks for putting something forward.

If I'm understanding your concept correctly, it's intended to offer a starter kit specific to each ActivityPub server, and it's either auto-applied or suggested to new users when they create an account on that server.

The past few weeks I've been discussing a version of ActivityPub starter packs with various people that has more flexible interaction modes: being created and shared by users, giving people the option to mention a starter pack in a post so clients can show specific UI for it (mainly a "follow all" button but also ways to explore the contents of the starter pack), and established accounts on different servers being able and encouraged to use and share starter packs from around the fediverse.

I'm personally a fan of the idea to build starter packs that can be used backwards-compatibly by people on current versions of AP platforms without specific starter pack support, by implementing starter packs as "boost bots" (actors of type Service) which follow all the accounts in the starter pack and boost their public posts. That way, people on older versions can follow the starter pack like a regular account and get its contents that way, while people on newer versions with specific support for starter packs can get a better UI with a "follow all" button to establish follow relationships that don't go through the bot account. (We'd probably want to establish some custom property that allows servers and clients to distinguish starter pack service actors from other bots.) Relating it to your concept, the starter pack collection would be the actor's following collection, although this would be unable to contain hashtags.

My design notes can be found here. I'm told Newsmast has a version of starter packs planned that matches my concept fairly closely. Neither of us have started a proper implementation yet.

Do you think it's possible to adapt your spec to fit these additional ideas too, or are the concepts too different?

Some relevant discussion threads I participated in:

https://ruby.social/@getajobmike/113442936451176472 (This one contains input from the Mastodon team.)
https://windbag.org/@adam/113445644571384633

Great to see this created! Two really good ideas here - server specific packs, and ones which replicate the Bluesky experience, where they have been very successful, passed around independent of servers. We have boost bot tech as @jfietkau mentions which could be repurposed for this. We’re just finishing an application of this approach to Fediverse custom feeds. Not underway yet on starter packs - just joining the discussion at the moment

@context | string | Required | Must be "https://www.w3.org/ns/activitystreams"

why? the @context may be different if there are extension properties, and also @context shouldn't be considered at all if you aren't doing LD processing. in other words, DO NOT ATTEMPT TO VALIDATE @context -- you are only introducing bugs!

type | string | Required | Must be "Collection"

type may be an array
it may use OrderedCollection instead of Collection
you may want to define an extension type to make it clear what the semantic purpose of this collection is -- StarterPack, RecommendationCollection, whatever

name | string | Not required | Human-readable name of the collection totalItems | number | Required | Total number of items in the collection

why is the name not required, but the totalItems is?

The items array can contain two types of objects:

why?

type | string | Required | Must be "Person" name | string | Required | Display name of the account

actors can be of any type, not just Person
why is name required, but nothing else? in most cases the data is untrusted and has to be fetched from origin anyway, so really the only "required" bit is the id.

type | string | Required | Must be "Hashtag" id | string | Required | URI identifying the hashtag

Hashtag should be defined in @context as as:Hashtag, since it is not officially part of the https://www.w3.org/ns/activitystreams context document
hashtags generally don't have an id, they have an href because they are a type of Link
hashtags also generally cannot be followed across servers, so what is this inclusion even trying to say? if i start a new server then every single "hashtag recommendation" is useless without a source for additional data.

Example Activity

this isn't an activity, it's a Collection object

more generally

i see a lot of problems with this conceptually. the schema has problems, sure, but those can be fixed; what is far more important is that i don't see any protocol or behavioral considerations here:

who is making these lists?
how are they making these lists?
how are these lists being discovered?
what is the expected user flow for using one of these lists?
how does someone grant consent to be on a list?
how does someone revoke consent for being on a list?
etc

there is a lot of thought that needs to be put into such a proposal before even getting to a schema, and unfortunately i'm not seeing any of it anywhere here.

For as:Hashtag we should reference https://purl.archive.org/miscellany from https://swicg.github.io/miscellany/

if i start a new server then every single "hashtag recommendation" is useless without a source for additional data.

This is correct, but for a user using a starter pack to join an existing server, hashtag recommendations may make sense.

The items array can contain two types of objects:

why?

The items array can contain any Actor type and any as:Hashtag might be a better way to put it?

any Actor type

actors can be any type. just because mastodon restricts you to 5 types doesn't mean that everyone else has to use only those 5 types

I'd argue against requiring approval to add people to new packs, but they should be notified with a button to remove themselves on demand.

I'd argue against requiring approval to add people to new packs, but they should be notified with a button to remove themselves on demand.

Generally speaking, for these "opt in or opt out" questions, I like to ask myself what is the kind way to treat people who have never heard of $thing and don't have time to investigate every new feature. We don't have an existing consent mechanism that matches starter packs exactly, but my feeling is that the discoverable flag should be taken into account when deciding whether it is okay to add someone to a starter pack.

I've been thinking something along these lines:

discoverable flag set and account does not manually approve followers: can safely be added to starter pack
something in between: ask before adding (Bridgy Fed style)
discoverable flag not set and manually approves followers or #nobot in bio: do not attempt to add to starter pack

I've been planning to treat #nobot as a general opt-out since in my concept, each starter pack is a bot account. Maybe that doesn't apply if you're working purely with lists.

On top of that, notifying someone when they're added to a starter pack and giving the option to self-remove makes sense. Within the possibilities afforded by current implementations, someone blocking the actor that corresponds to the starter pack could be interpreted as "I want no part of this". It would be nice to have a way to say "allow all" and "deny all", but that's a bit harder unless all starter packs go through a central server.

Is this the right place to discuss this type of starter pack? If it's extremely out of scope for what Pixelfed starter kits are trying to accomplish, then I don't want to be rude about pushing this. But my impression is still that the schema would ultimately not be all that different and that it's worth avoiding having a handful of mutually incompatible types of ActivityPub starter packs with slightly different features.

You have Collection as an example of an Activity. That's not really an Activity. Maybe use Create, instead.

Depending on answers to the general questions raised by @trwnh, I’m surprised the schema does not include a field for “notes”/“comments” in each item. IFF starter packs are to be something people create for other people, AND items are to be followed individually (e.g. via checkbox), I feel like the curator(s) may want to include a brief explanation what the item in question is/why it‘s included: While hashtags don’t offer any kind of information beyond their name, even accounts with a useful self-description on the profile (not a given!) are likely to benefit from curator-supplied notes.

After mulling it over for a bit...

Schema suggestions

I suggest adding the following two properties to your base structure:

attributedTo: An actor who owns this starter pack and who is responsible for it in case of abuse or other rule violations.
image: Comparable to Mastodon's image property on actors (TIL that that's not in AP core), a rectangular splash image that can be used to visually represent this starter pack. I reckon this one can be optional, but it's nice if the starter pack can supply a collage of the profile pictures or something else that visually makes sense, not least so the receiving server and client don't need to fetch all of the included profiles just to visually render a starter pack. I suggest borrowing the OpenGraph recommendations for image formats, aspect ratio, and sizes.

I'm also inclined to agree with @trwnh's suggestion of coining a sub type of Collection for these things. I'm going to call them FollowRecommendations from here on because I find that the clearest one for what they are and what they contain. (Colloquially and in clients they can still be called starter packs, that's fine.)

Mockup

Way off in utopian future dream land, with support for rich rendering of starter packs in all clients and servers, they might look something like this if I attach one of my own starter packs to a public post:

A rough rendering of a Mastodon-like post with an author name and handle, posting time, and text. Attached to the post (not unlike a link preview) is a starter pack consisting of a splash image showcasing the avatars of 16 included profiles, the starter pack title, its curator, information about the number of accounts, and a 'follow all' button.

You can do a one-click "follow all", or if you click on the splash image or the title, you'd get a detail UI along these lines:

The same starter pack as before, this time as a list view: title and curator as well as profile count and 'follow all' button at the top, followed by a vertical list of the included profiles, each with avatar, display name, handle, and follow button. One profile has a text label '(Already following)' instead of a follow button.

Note that this only covers consuming starter packs. The authoring UI would likely be a bit more involved, but could probably piggyback on existing list management features, for platforms that have those.

Backward compatibility

I already mentioned that one of my design constraints is getting these things into people's hands soon, like on the order of single-digit months (low single digits ideally). That means I don't want to rely on every server and client out there implementing specific support, releasing updated versions, waiting for people to upgrade, etc.

So to make these starter packs work with the facilities that we can currently use, I propose that we come up with a way to (optionally) wrap a starter pack in a service actor to make it followable, taggable, and otherwise interactable.

So you'd have something potentially like this:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://starterpack.example/bot/ac3d1493-2a35-400a-a920-8250388605ed",
  "type": "Service",
  "following": "https://starterpack.example/bot/ac3d1493-2a35-400a-a920-8250388605ed/following",
  "followers": "https://starterpack.example/bot/ac3d1493-2a35-400a-a920-8250388605ed/followers",
  "inbox": "https://starterpack.example/bot/ac3d1493-2a35-400a-a920-8250388605ed/inbox",
  "outbox": "https://starterpack.example/bot/ac3d1493-2a35-400a-a920-8250388605ed/outbox",
  "preferredUsername": "ap-devs",
  "name": "ActivityPub Developers",
  "summary": "Follow this account to subscribe to the ActivityPub Developers starter pack curated by Julian Fietkau!",
  "url": "https://starterpack.example/ap-devs",
  "published": "2024-12-24T00:00:00Z",
  "publicKey": {
    (...)
  },
  "attachment": [
    {
      "type": "FollowRecommendation",
      "id": "https://starterpack.example/pack/ac3d1493-2a35-400a-a920-8250388605ed",
      "name": "ActivityPub Developers",
      "attributedTo": "https://fietkau.social/users/julian",
      "summary": "Description of these recommendations",
      "image": {
        "type": "Image",
        "mediaType": "image/png",
        "url": "https://starterpack.example/images/splash/ac3d1493-2a35-400a-a920-8250388605ed.png"
      }
      "totalItems": 16,
      "items": [
        (...)
      ]
    }
  ],
  "icon": {
    "type": "Image",
    "mediaType": "image/png",
    "url": "https://starterpack.example/images/icon/ac3d1493-2a35-400a-a920-8250388605ed.png"
  },
  "image": {
    "type": "Image",
    "mediaType": "image/png",
    "url": "https://starterpack.example/images/splash/ac3d1493-2a35-400a-a920-8250388605ed.png"
  }
}

The above is a bog-standard service actor except for the attachment of type FollowRecommendation. Clients and servers without support for starter packs would ignore the attachment and render it as a bot account. This actor would be created when the curator (in this example that's me) authors a starter pack. The bot actor would follow each member of the starter pack, and only if the follow request is accepted, that person would be added to the starter pack's items (and its splash image). Going forward, the service actor would Announce (boost) every member's posts if they have as:Public in to or cc. If the service actor were ever blocked by a person currently in the starter pack, that person would be removed from the starter pack. See my earlier comment for slightly more detailed thoughts on trust and safety and the "opt in our out" question.

These service actors could be implemented and hosted on a purpose-specific ActivityPub server. With no changes to current clients or servers, they would be followable by people on ActivityPub platforms, thereby adding all public posts by members to the follower's home feed, like a LitePub relay or one of those feed bots by Newsmast. The bot could also made to be smart enough to reply with a "follow me to subscribe to this starter pack" Note whenever it's publicly tagged by someone.

Going forward, ActivityPub platforms could add support for FollowRecommendation starter packs by rendering a better starter pack UI in place of these service actors if a FollowRecommendation attachment is present. This would allow a smooth entry into an ActivityPub world that supports starter packs. Whenever most people are on future compatible versions, we can phase out the service actors and let people attach starter packs to their posts or profiles directly.

Pro:

Implementable and compatible ~today (<-- this is the big one IMO)
Would look fairly sleek on most clients
Low friction for consuming starter packs, just follow the account
In other words: no off-platform steps needed (no web form, no CSV import, no OAuth step)
Could still have an additional website with a "Log in with Mastodon" button that authorizes an API call to add all the accounts to your follows

Contra:

Is kind of a hack
People who click "follow" on a starter pack actually follow a bot account instead of the individual people in the starter pack, so the connections are not as direct as I would like
If someone follows some of the people in a starter pack as well as the service actor, they'd receive each post twice, first as a direct delivery and then as an Announce by the bot. I know Mastodon is supposed to filter these out if they arrive in quick succession. Are other platforms smart enoough for this too or will people see double posts?
My above example skips over a thorny open issue re: ownership. If we host these service actors on bespoke ActivityPub servers for the time being (until platforms add native support to let people create and share starter packs), it's difficult to host a FollowRecommendation on one origin with attributedTo set to an actor on a different origin. I'm thinking in terms of FEP-c7d3 here. How do we prevent falsely attributed starter packs without the support of the author's AP platform? The only sensible stopgap I can think of is Mastodon's new attributionDomains used for the fediverse:creator meta tag. We could ask people to add the starter pack server they use to that.

Authoring starter packs

A specific web UI to create starter packs could be hosted on the bespoke AP server. It would let people authenticate with their AP account via OAuth and then let them put together starter packs by adding individual accounts, setting titles and descriptions and whatnot, maybe customizing the splash image a bit. Adding accounts would follow the safety constraints discussed in my earlier comment (subject to change by recommendation of more qualified people, e.g. how to handle federated moderation reports on a starter pack or its service actor).

I'm kinda handwaving this part of the process right now. I'll just say that I believe that authoring starter packs can be a slightly higher friction process (e.g. log in on an external website) without necessarily being disastrous. I'm sure there are more details to figure out, but this comment is already long enough, plus if any of the above accidentally made me sound competent at this, I need you to know that I'm still just a lil ActivityPub baby and I don't know how to namespace or how to LD a JSON and if you ask me I should really not be in charge of this 🤯 but someone's gotta do the work, so let's go.

@jfietkau on

People who click "follow" on a starter pack actually follow a bot account instead of the individual people in the starter pack, so the connections are not as direct as I would like

You could have the starter pack actor respond to follow requests with a direct note back saying "check my following instead"

And then link to the FollowRecommendation collection via the following property.

You could have the starter pack actor respond to follow requests with a direct note back saying "check my following instead"

Hmm, that would work for forcing direct follow relationships, but it would ruin the "one click to subscribe to a starter pack" value that I'm rather attached to.

I would prefer to untangle those service actor follow relationships at some point though. Maybe when platforms add explicit support for starter packs, they could go through the existing ones they know of and turn local followers of starter pack service actors into direct follow requests for each of the starter pack's members.

Then again, we might still like to keep a record of which starter packs someone has subscribed to. Something I haven't spent much time thinking on is what to do with changes to starter packs. If the follow is through a service actor, followers always see posts by everyone currently in the starter pack and that's it. But if in the future I click "follow all" on a starter pack and the curator later adds more accounts to that pack, do I want to auto-follow those as well? What about removals? Or should starter packs be immutable once published? Maybe what we should do is disable the "Follow all" button if the person is already following everyone in the starter pack, and re-enable it if they're not. Needing to periodically re-check my favorite starter packs in case new people have been added to them might be the path of least unpleasant surprises.

And then link to the FollowRecommendation collection via the following property.

These could be merged, good point.

i'm hesitant to drag the conversation into technical details again because i'd still like to see more protocol and behavior considerations as a pre-requisite to schema discussions, but i think this is close enough to respond to:

re: using `discoverable` for opt-in consent

https://joinmastodon.org/ns#discoverable does seem like it could be taken a symbol of general consent or opt-in regarding all manner of "discovery services", but with the caveat that mastodon does not communicate to users the full scope of what those users are opting into here. this lack of clarity was in fact a big part of the reason why a separate https://joinmastodon.org/ns#indexable was defined for opting into full-text search.

it's not entirely clear what is or is not consented to here, but it may be sufficient to assume consent given that this is a sort of "discovery service" and the current explanation includes text that says that "your profile may be suggested to other users". the further caveat is that some users opted into being discoverable back when the scope was far more limited (to just the mastodon "profile directory" feature), but i think that we can probably say that this is an issue of raising awareness that ecosystem-wide, being discoverable means more than what it used to mean 5 years ago.

re: @jfietkau's mockup

"follow all" without having any idea what's in the list seems like a dangerous action, so i think the mockup should instead have a "see more" kind of button or otherwise re-use the space to show more information.

re: @jfietkau's proposal

it makes sense to have an actor representing a "list" (doesn't have to be a Service but Service or Application seems as good/bad as any of the ones mastodon will force you to use)

sending follow requests makes a bit less sense. sure, it actively notifies the person that they have been added, but it also has the side effect of subscribing to future activities. so at minimum you will need an inbox endpoint that... drops most incoming activities? idk what the correct move is here. but if you're willing to deal with increased network traffic then sure it's an okay idea

the attachment of a FollowRecommendation feels less justifiable and also FollowRecommendation could use more clarity on what it is. if we're going with the actor idea, it's actually extraneous and unnecessary -- just put the metadata of the "starter pack" directly on the "starter pack actor".

the actor sending an Announce for everything posted by a followed/included user can be kinda spammy. if i got added to a few "starter packs" and it meant that every single time i posted anything public i would immediately receive multiple notifications, that seems very annoying. i guess i could mute notifications from those "starter pack actors" but yeah i'd rather not have to do that

For @jfietkau's:

Hmm, that would work for forcing direct follow relationships, but it would ruin the "one click to subscribe to a starter pack" value that I'm rather attached to.

We could offer that via a website through which you sign-in with your account (profile read:follows write:follows scopes) and then we have UI that allows you to follow all or follow individually. Though this would depend on the software supporting oAuth and those scopes as well as RFC8141 to discover available scopes.

That's already what I was intending to do for my "starter pack" service thing.

re: using discoverable for opt-in consent (...)

That sounds encouraging to me, thanks!

"follow all" without having any idea what's in the list seems like a dangerous action, so i think the mockup should instead have a "see more" kind of button or otherwise re-use the space to show more information.

The "see more" thing would be the default action if you click the title or the splash image. I included the "follow all" button for cases where you trust the starter pack's curator and really do just want to follow their recommendations without checking each of them one by one. I think some Bluesky starter packs get quite large and many people like a busy feed.

Let me see if I understand the danger part. A malicious starter pack could make you follow (1) spammers (2) fake accounts impersonating people you would have otherwise liked to follow (3) people who intend to cause you direct harm. Any of these experiences could range from annoying to unsettling to potentially dangerous. So yeah, following a malicious starter pack could be bad.

The question is under what circumstances you would follow a malicious starter pack. There are many people I follow whose starter packs I would trust blindly, but in practice I'm probably obsessive enough about my home feed to check them over in detail anyway. I think some people might not care as much, and would click "follow all" on starter packs made by their friends. Is the danger of someone clicking "follow all" on a dodgy starter pack large enough that we should take the quick option away from people? I mean, at worst you're following some bad actors. That doesn't give them access to anything in particular and is fairly quickly reverted.

I don't know how people feel about this point in general. My gut feeling is having a "follow all" action for those who want it is valuable. How exactly does Bluesky do it, what does their UI for this look like? I can't easily find a screenshot.

sending follow requests makes a bit less sense. sure, it actively notifies the person that they have been added, but it also has the side effect of subscribing to future activities. so at minimum you will need an inbox endpoint that... drops most incoming activities? idk what the correct move is here. but if you're willing to deal with increased network traffic then sure it's an okay idea

This goes hand in hand with the Announceing of the person's public posts. The service actor needs to receive them in the first place in order to be able to do that.

the attachment of a FollowRecommendation feels less justifiable and also FollowRecommendation could use more clarity on what it is. if we're going with the actor idea, it's actually extraneous and unnecessary -- just put the metadata of the "starter pack" directly on the "starter pack actor".

Re: semantics of FollowRecommendation, I've been reading it as "If you would like to see more about this specific topic, here's a vetted list of profiles (and potentially hashtags) to follow, as curated by this person. Follow all, follow some, do as you like."

Re: should a starter pack itself "be" an actor: should it? I mean above you did write "might as well", but tbh I see them more as just some passive information, like in Dan's original proposal up top where they're a flat list of objects. My design for wrapping a FollowRecommendation (being a Collection) in an actor that follows and announces and does a bunch of other stuff is just intended as a backward compatibility hack that's needed until platforms add real support for starter packs. Until then, you'd have these service actors that use a FollowRecommendation list to enable functionality not yet offered by the platforms, and you might also in parallel have what Dan up top called a starter kit, where an admin-configurable FollowRecommendation object is used by the server to present it during new user onboarding. In the long term, as platforms add support, we'd (hopefully?) be able to get rid of the service actors and share FollowRecommendations directly. That's why I tried to separate the actual data structure that might get used in different contexts from the auxiliary scaffolding that establishes a mini relay bot.

But also, when someone in the future wants to share a starter pack they made in a platform that supports them, it would make sense to me to let them attach a starter pack to a Note just like one would an image. So maybe FollowRecommendation in attachment isn't all that weird if I think about it.

the actor sending an Announce for everything posted by a followed/included user can be kinda spammy. if i got added to a few "starter packs" and it meant that every single time i posted anything public i would immediately receive multiple notifications, that seems very annoying. i guess i could mute notifications from those "starter pack actors" but yeah i'd rather not have to do that

This is true and I think it's sadly unavoidable in this design when using service actors to fan out posts to followers. or at least I can't think of a way to avoid it.

We could offer that via a website through which you sign-in with your account (profile read:follows write:follows scopes) and then we have UI that allows you to follow all or follow individually. Though this would depend on the software supporting oAuth and those scopes as well as RFC8141 to discover available scopes.

That's already what I was intending to do for my "starter pack" service thing.

I would like to offer this separate web UI as well, in addition to the boosting service actor. The way it enables direct follow relationships is a big advantage.

I just don't want it to be the only way to follow a starter pack. Clicking an external link, vetting if the website is trustworthy enough to OAuth my Mastodon account, entering my instance name, doing the OAuth process, and then triggering the subscribe action... that's a long process with a lot of friction. You'll lose a chunk of people at every single one of those steps. The fediverse has had "high friction" starter packs for a while (see Academics on Mastodon, FediRoster, Fedi Garden, ...) that take minutes of work to import. The thing that makes Bluesky starter packs so successful is their ease of use. You see someone on your feed posting a cool starter pack, you click "follow" and you're done. Without starter pack support in future versions of platforms, I think the service actor concept (which, again, can coexist with a separate website with OAuth support) is the only way that gets us there before 2026.

Oops, I probably should have tagged you both, sorry. @trwnh @ThisIsMissEm

I'll also temper my last comment a little after sleeping on it: I've seen "starter packs" and follow recommendation lists for manual one-by-one adding and with CSV ex-/import for mass following. I have not seen the OAuth + Follow API approach done in practice anywhere yet. As much as I still think requiring authentication on an external website is friction, I also think it will be much more convenient than handing people a four step howto on importing CSV follow lists.

Anyhow, it sounds like Dan's first public prototype is due out any moment, so we'll see live and in public which parts of this discussion have already been incorporated. 😀

pixelfed / starter-kits

Schema #1

StarterKit Extension Documentation

Specification

Base Structure

Properties

Item Types

Person Objects

Hashtag Objects

Example Activity

more generally

Schema suggestions

Mockup

Backward compatibility

Authoring starter packs

re: using `discoverable` for opt-in consent

re: @jfietkau's mockup

re: @jfietkau's proposal

pixelfed / starter-kits

Schema #1

StarterKit Extension Documentation

Specification

Base Structure

Properties

Item Types

Person Objects

Hashtag Objects

Example Activity

more generally

Schema suggestions

Mockup

Backward compatibility

Authoring starter packs

re: using discoverable for opt-in consent

re: @jfietkau's mockup

re: @jfietkau's proposal

re: using `discoverable` for opt-in consent