Expose the list of accounts for a given starter pack (API?)

[davidbgk]

It would be handy to be able to retrieve the list for other external usages.

I'd love to be able to collect feeds for 🪐 SimPlanet for instance.

[anze3db]

@davidbgk hey! thanks for opening the issue. I think you are the second person asking for an API so for. Can you give me an idea of what you expect the API to return and in which format (json, xml, etc). Thanks!

[davidbgk]

@anze3db great! The minimum would be the name, description and author's handle of the pack and the list of mastodon handles. From here we can iterate :)

About the format, whatever you prefer to deal with, JSON is OK and should not require an external dep with Django.

[jfietkau]

Rather than inventing a bespoke API just for this service (or maybe in addition), please consider coordinating with other ActivityPub implementers on an in-protocol representation of starter packs, so we can get to a point where they can be used by different server implementations and rendered natively in clients.

@dansup is working on an implementation as part of Pixelfed, there is some discussion here: pixelfed/starter-kits#1
I remember there seemed to be some amount of collaboration on this between Pixelfed and Mastodon, but I don't know if it was public.

[anze3db]

I'm happy to adopt the schema defined in pixelfed/starter-kits#1, but I'm not sure how/where to even start collaborating on an in-protocol representation. I'm happy to release a simple API that we can use test the waters and gather some feedback to help guide in-protocol representation and other implementations.

[jfietkau]

I'm likewise out of the loop regarding communication channels. If I hear anything I'll let you know.

[jfietkau]

Update: The WordPress ActivityPub plugin (cc @pfefferle) has adopted the Pixelfed schema (cc @dansup) I linked above for the consumption of starter packs: https://activitypub.blog/2025/07/23/7-1-0-polishing-tables/

WordPress isn't emitting any starter packs/kits (as yet), but adding support to Fedidevs for this schema would enable WordPress users to consume/follow all the ones that Fedidevs hosts. Since Mastodon hasn't made visible progress on theirs lately, I guess at least for now the Pixelfed starter kits are what the ecosystem is converging on.

What would it entail for Fedidevs to add support for this? I would say:

1. Generate a valid ActivityPub object in JSON-LD format for each public starter pack you host. Since Dan's schema just models them as a Collection, you don't even need any custom @context. In the simplest case, you'd just fill items with the actor IDs (note: actor IDs can differ from profile web links, e.g. for Mastodon profiles) and update the totalItems count.
2. I still feel strongly about the two added attributes I proposed: attributedTo linking to the starter pack's author, and (optional but useful) image providing a splash image that the starter pack service can pre-render, for example as a collage of the avatars and possibly with branding for Fedidevs. Bluesky's starter packs do both, and I think having a visual representation of the starter pack is useful and offers a point where different starter pack services can offer differentiation.
3. Make the ActivityPub objects available via content negotiation: check the HTTP request's Accept header and respond with AP data if asked for. Or if need be, host them on a separate URL and use other signals for discovery.

I think that's about it. Still sound like something you'd be down to tackle? I haven't looked at your source code here yet, but many of my projects are in Python and I might be able to help a bit.

[anze3db]

Sorry for the late reply I was at a conference last week and I'm still trying to catch up with work things.

Yes, I'm still interested in providing an API for starter packs. I made a prototype on the api branch a few months back but I didn't manage to push it over the finish line. Feel free to pick up the work and make the schema match the one from Pixelfed.

I also wanted to have splash images like bluesky from the very start but never got around to doing it. It would be a very cool feature!

[jfietkau]

I'm fired up and got started hacking away at the Fedidevs code base. My personal roadmap for this issue:

1. Make sure we have ActivityPub IDs in the database for all accounts – started in Add ActivityPub ID to account model and to account crawling functions #175, still requires discussion and additional implementation work.
2. Serve ActivityPub versions of published starter packs – I already have this working locally (minus the required ActivityPub IDs from step 1), it's like 20 LOC, dead simple. My approach is based on the existing Django routing and doesn't use any of the stuff from the API branch, which I haven't examined in detail.
3. When step 2 is finished, I can start working on the splash images. We gotta discuss the design in a separate issue since it's off topic for this one, but if we're fine with pulling in Pillow as a dependency, I'm confident I can put a nice implementation together.

[anze3db]

Regarding 2.: if you managed to get it working without an extra dependency like django ninja then even better 😄

Regarding 3. I'm not against adding Pillow as a dependency. I don't think strongly about the design because anything will be better than what we currently have 😅 Feel free to do what you think looks good and we'll adjust after if needed.

[jfietkau]

As of #177 we have a JSON API per starter pack as well as an ActivityPub one.

Hey @davidbgk, does the JSON API (example) suit your purposes? You can get the contents of a specific starter pack either using the format parameter or via HTTP content negotiation. This is currently only for accessing a specific starter pack whose URL you know, it can't search or list all of them.

On the ActivityPub side, we're currently interoperable with WordPress. Mastodon just announced that they will be publishing their starter pack spec relatively soon. I was able to get a few preliminary questions answered, and based on that info, we're looking at some additional work in however many months time if we want to be compatible, but no breaking changes. I'm happy with where we stand until the spec work progresses more.