dnd.vielle.dev requires you to have an atmosphere account. An atmosphere account is an account used for atproto, which is an internet protocol (like email, https, or tcp) designed for creating social media sites easily with user agency, credible exit, and data ownership.
Using atproto provides a couple of major benefits for app devs and users:
For dnd.vielle.dev, atproto gives a few improvements for free over local storage:
This is somewhat technical/confusing! You don’t need to understand this to create an account, but I reccomend you read this anyway to understand what atproto is and how it works. Ask me if you have any questions!
An account consists of a few core components:
In atproto, your did is a unique, permenant username for your account. vielle.dev has a did of did:plc:4zht3z4caxwrw3dlsybodywc, while ducky.ws has a did of did:web:didd.uk. If you lose control over your did (hard to do) you lose control over your account.
A handle is the user friendly username for an account, and can be changed. Every handle is a domain (like google.com or vielle.dev) so you can use a domain you own (if you have one), or one provided by your pds (below) (like jcsalterego.bsky.social or shame.evil.gay) if you dont.
The pds is where your account lives. This is a server which hosts account data and you can easily “migrate” from it to another pds — move between them — without breaking your account or data. Some pdses are free to join (like bsky.social, blacksky.app*, and selfhosted.social), while others are invite only (like abnormal.zip, katproto.girlonthemoon.xyz, and northsky.social**). More details about specific pdses are below
Your repository is the (public — for now) data you create on “the atmosphere” (atproto). This is things like bluesky likes/posts, teal.fm scrobbles, wisp.place sites, etc. You can easily export your repository as a car file, which is then used to move your account to another server without breaking data. Details on securing your account are below
Blobs are the (public — for now) files you post to “the atmosphere”, including images on a bluesky post, or images in your leaflet entry. You can export and backup all your blobs if you want, but it isn’t as necessary as your car file, since if they don’t migrate, you’ll just have broken images. Blobs are imported when you migrate your account.
Choose a pds. You can choose a public pds (or a private pds if you get an invite code). A few reccomended options are listed here.
Create an account on the instance. Some pdses provide a custom signup screen, but many do not. For those that do not, you can click the link labeled “Create an Account Here”, or use bsky.app. If you use bsky.app, click Create Account, then look for the small text that says “You are creating an account on Bluesky Social” and click the text Bluesky Social. Then, click custom and enter the address of your pds (ex: https://abnormal.zip/), and follow the standard signup instructions.
Done! If you want to migrate to a new server (ex, you selected bsky.social), follow the instructions here
https://bsky.social/ — This is the “flagship” pds instance operated by bluesky. Signup is open to everyone, and anyone can migrate away from it. If you have an existing bsky.social account, you can migrate back. If you’re really worried about your account you could sign up and migrate away so you can migrate back later (⚠️ I haven’t tested migrating to bsky.social! ⚠️), but several companies now rely on atproto for their existence, and many alternate pdses are open so I don’t think this is an important concern. In the future I believe bluesky plan to open up incoming migrations — once the ecosystem has more open pdses with more users.
https://blacksky.app/ — This pds is operated by blacksky. Avaliable handles are .blacksky.app, .myatproto.social, and .cryptoanarchy.network. .blacksky.app is only allowed for black users (not any POC — specifically black). I reccomend checking out https://blackskyweb.xyz, https://blackskyweb.xyz/overview, and https://docs.blacksky.community/ before migration. Create an Account Here
https://selfhosted.social/ — This pds is operated by respected community member @baileytownsend.dev and is used by many atproto based apps as their default pds signup instance. Create an Account Here
https://tophhie.social/ — This pds is operated by tophhie.cloud. I don’t know much about them — do your own research. Create an Account Here
https://tngl.sh/ — This pds is operated by @tangled.org. This pds is designed for users of the atmosphere app tangled.org and does not support incoming migrations. Create an Account Here
https://zio.blue/ — This pds is operated by community member (and my mutual) @ducky.ws and @astra.blue. If you want an invite code you need to DM @zio.sh on bluesky, which means this pds does not support new users (unless you get someone to message for you). zio.blue bypasses age verification requirements due to laws like the Online Safety Act. Create an Account Here
https://northsky.social/ — This pds is for “2SLGBTQIA+ people” with — at the time of writing — a waiting list for sign ups. See northskysocial.com for more information.
https://abnormal.zip/ — This pds is operated by me and runs off a pi on my desk. Invite codes are required — message me for one and I’ll hook you up. Avaliable handles are .abnormal.zip, .pds.vielle.dev, .at.vielle.dev, and .at.dongs.zip. I ask that .pds.vielle.dev is reserved for john-doe.pds.vielle.dev and .at.vielle.dev is reserved for specifically my alts. If you use one of these handles I will ask you to change it. If you do not change it I’ll figure out how to change it for you. Create an Account Here
Selfhosting — ⚠️ HERE BE DRAGONS — PROCEED WITH CAUTION ⚠️ — If you have your own domain you can host your own pds. https://atproto.com/guides/self-hosting, https://github.com/bluesky-social/pds, and https://github.com/bluesky-social/deploy-recipes are good guides for using the reference implementation of the pds. Alternative pds implementations include rksy-pds by blacksky, cocoon by hailey.at (former bsky dev), and tranquil pds by @lewis.moe and @nel.pet.
Migration is a somewhat risky operation (mostly safe but sometimes you can run into issues — I reccomend creating a backup beforehand and getting in touch with me if you have problems) but is fairly easy to do thanks to https://pdsmoover.com/ by @baileytownsend.dev. Make sure to read over https://pdsmoover.com/info before migrating, and I reccomend following the video by @sharpiepls.com — obviously replacing blacksky.app and the handles with whichever pds and handles you’re using.
Securing your account protects your account from a hostile pds and consists of 2 main components:
Once again pds moover can help and make things easy. Head to https://pdsmoover.com/backups, and enter your accounts handle and real password — read everything carefully, backups are important and can be risky if you’re reckless.
On the next screen, make a new rotation key (following the onscreen instructions by getting the plc token email), and save it to your password manager. Make sure you remember where you save it. If you can’t save this to your password manager, download the key file and save it somewhere safe. If you lose this key you could lose your account (if the pds becomes hostile).
This also creates a daily backup of your account, including both records and blobs. The most common case of a hostile pds is the pds going offline — pds moover is sufficient if this is the only concern you have.
Resolve your handle/did to your pds. Theres a good guide here, but you can also just hardcode it if you want, as long as you remember to change it whenever you migrate
Call /xrpc/com.atproto.sync.getRepo?did=<your did> to get your car file and save it somewhere. If you want history, call /xrpc/com.atproto.sync.getRepoStatus?did=<your did> to get the current rev, or extract it from the car file to use as a filename. Or you can use the date. If you don’t care about blobs you can stop here
Call /xrpc/com.atproto.sync.listBlobs?did=<your did> to get a list of all your blobs. If the number of cids is equal to 500 (or whatever limit you set in the request), repeat the call with &cursor=<cursor from last request>, and append cids until you get a number of cids less than 500.
For each blob, call /xrpc/com.atproto.sync.getBlob?did=<your did>&cid=<current cid> and save the blob response. Its reccomended to use the cid (or <cid>.<filetype>), since the cid is a hash of the contents and so won’t change. If you restore a blob that isn’t being used in the repo, it will get deleted after roughly an hour.