Starter packs and relationship to underlying moderation lists #3099
Replies: 1 comment
-
What you are looking for here is to have a starter pack that is referencing a list of type The easy way to do this, is to create a pinnable curation list like normal, and then hand craft the app.bsky.graph.starterpack entry: {
"collection": "app.bsky.graph.starterpack",
"repo": "did:plc:[MY_PLC_ID]",
"record": {
"name": "[STARTER_PACK_NAME]",
"list": "at://did:plc:[MY_PLC_ID]/app.bsky.graph.list/[EXISTING_LIST_IDENTIFIER]",
"feeds": [],
"createdAt": "[TIMESTAMP]",
"$type": "app.bsky.graph.starterpack"
}
} Obviously I filled in the text in square brackets with appropriate values. Once you create this record, you should be able to simply maintain the existing list as normal, and the starter pack would remain in sync. It might be possible to update an existing starter pack's list to change the type, or to update an existing starter pack to swap out the list, but I've not tried this. Some form of caching might prevent it, much like how post edits do not show up in the appview. As for how I created the record, I did it in the browser console with code like the following, which I based on what was sent when I used to UI to create a list, thus some of the headers might be overkill. fetch("https://[MY_PDS].[MY_PDS_REGION].host.bsky.network/xrpc/com.atproto.repo.createRecord", {
"headers": {
"accept": "*/*",
"accept-language": "en-US,en;q=0.9",
"atproto-accept-labelers": "did:plc:ar7c4by46qjdydhdevvrndac;redact",
"authorization": "Bearer [MY_TOKEN]",
"cache-control": "no-cache",
"content-type": "application/json",
"pragma": "no-cache",
"priority": "u=1, i",
"sec-fetch-dest": "empty",
"sec-fetch-mode": "cors",
"sec-fetch-site": "cross-site"
},
"referrer": "https://bsky.app/",
"referrerPolicy": "origin-when-cross-origin",
"body": "{\"collection\":\"app.bsky.graph.starterpack\",\"repo\":\"did:plc:[MY_PLC_ID]\",\"record\":{\"name\":\"[STARTER_PACK_NAME]\",\"list\":\"at://did:plc:[MY_PLC_ID]/app.bsky.graph.list/[EXISTING_LIST_IDENTIFIER]\",\"feeds\":[],\"createdAt\":\"[TIMESTAMP]\",\"$type\":\"app.bsky.graph.starterpack\"}}",
"method": "POST",
"mode": "cors"
}); |
Beta Was this translation helpful? Give feedback.
-
Hi, my apologies if this isn't the best place to ask this question. I wasn't sure what falls under the boundary of the atproto protocol vs the bluesky app interface.
While playing with the python atproto api, I found that starter packs (as with this api) have a corresponding list given by
response.starter_pack.list.uri
(e.g.at://did:plc:.../app.bsky.graph.list/...
).I can view that list in my browser by constructing a url e.g.
https://bsky.app/profile/marcmarone.com/lists/<list_uri_from_above>
.I can also follow example code like here: https://github.com/MarshalX/atproto/blob/main/examples/advanced_usage/add_user_to_list.py , to add a user to the underlying starter pack list. When I do this, I see the user also appears in the starter pack interface.
My questions:
When viewed in my browser, the list underlying the starter pack shows as a "moderation list". Can I treat that list as the cannonical list backing the starterpack? Meaning I can make programmatic modifications to the list and see the changes reflected in the starter pack that I've shared with others.
I notice that I don't have an option to pin this list to home, as I do for normal lists. Is this because of its special status underlying the starter pack? Or perhaps because it's called a "moderation" list?
There seem to be limits on the size of starter packs. What happens to my starter pack if I grow the underlying list?
My goals are to have a starter pack of users and corresponding list, that crucially can be viewed as a feed (seems pin to home is the best mechanism for this). My plan was to use a script to sync a starter pack (or several) to a list. But if there's a better way to go about this, please share, thanks!
Beta Was this translation helpful? Give feedback.
All reactions