Who Is Behind That Bluesky or Mastodon Account? First Work Out Who Holds the Record.
On a centralized platform the question has a defendant: one company, one legal department, one address for service. Bluesky and Mastodon break that assumption. Mastodon is thousands of independently run servers, many operated by one person as a hobby. Bluesky runs on a protocol where the name you see is a domain name and the account’s data may sit on hardware its owner controls. So the useful question is not “how do I unmask this account” but “does a record of this person exist anywhere, and who is holding it” – and this page answers that honestly, including the times the answer is nobody.
The short version
There is no single company to serve, and that is the whole shape of this problem. On Mastodon, the records that could bear on identity – a confirmed email address, connection addresses, whatever the software logged – sit with the operator of the one server the account signed up on, and that operator is frequently a volunteer with no legal department, no published retention schedule, and no obligation to a stranger who writes in. On Bluesky, the visible handle is a domain name and the permanent identifier is a DID, and the server holding the account’s data is named in that DID’s document; it can be a large hosting service or the account holder’s own machine. Where a real matter needs a name, the route is lawful process aimed at whoever actually holds the record, and that route belongs to an attorney. Where the matter is harassment, the faster path is the network’s own report channel, evidence preserved properly, and law enforcement. We do neither by guesswork, and we publish no method for unmasking anyone.
Watch: why federation changes the question you should be asking
A short briefing on the difference between a platform you can write to and a network of independent operators who each hold a fragment.
Short briefing
Who actually holds the record, network by network
Everything downstream depends on this. Aim a request at the wrong party on either network and you get silence, which people then misread as stonewalling.
Start with Mastodon, because it is the more counterintuitive of the two. Mastodon is not a service you join; it is software that thousands of separate operators install and run, each with their own rules, their own moderators, and their own machine. An account lives on exactly one of those servers – the one it was created on – and that server is the only place its sign-up records exist. Everything else on the network holds copies of what that account has published in public, not the account itself.
What does the home server necessarily handle? Mastodon’s own administrator documentation is the honest source here, and it describes the mechanics plainly: signing up requires confirming an email address, sign-ups are rate-limited by address of origin, and the moderation interface includes an IP Rules page for blocking specific IPv4 or IPv6 addresses or entire ranges. A system that can rate-limit and block by network address is a system that sees network addresses. None of that tells you what any particular operator retains, for how long, or whether they keep logs at all – and that variation is the point. A large, well-run server may have a published policy and a lawyer on call. A server run by one person for forty friends may have neither, and may be under no practical obligation to answer a stranger’s email.
Bluesky is built differently and the difference matters. The AT Protocol documentation describes two interrelated identifiers for every account: a handle, which is a DNS name, and a DID, a decentralized identifier following a W3C standard, which the specification describes as the stable, canonical identifier for the account. Handles change; DIDs are designed never to. That is why the count on this page is two identifiers rather than one – the name you can read and the identifier the software actually uses. Resolving a DID returns a DID document, and the specification says that document carries three things: the handle associated with the DID, the signing key, and the URL of the user’s data server.
Read that last item again, because it is the whole answer to “who do I contact”. The account’s data host is published, by design, in a machine-readable document. It is not hidden. For most accounts that host is the service the person signed up with; the protocol documentation walks through a hosting-service example in which the handle is a subdomain the host issued. But it also walks through a self-hosting example in which the handle is the person’s own domain, the identifier is a did:web derived from that domain, and the hosting service is the same domain – the account holder’s own server. When that is the arrangement, the party holding the data and the party you would be asking about are the same person.
So the honest summary is that neither network has a single custodian. Bluesky Social PBC, which publishes the protocol and operates the app most people use, is one holder among a possible many. On Mastodon there is no company at the center at all. If you have arrived here from a centralized platform, the closest familiar comparison is a self-hosted website rather than a social network, and the same logic that applies to tracing the ownership of a website nobody has put a name to applies more than the logic of a social media help desk.
A handle is a domain name, and that is a real signal
Both networks contain one genuinely public, lawfully checkable claim of identity. Both are widely misread as proving more than they do.
On Bluesky, an account can take a custom domain as its handle. The protocol’s handle specification sets out exactly two ways this is confirmed: a DNS TXT record published at the _atproto sub-domain of the handle – so the handle user.example.com requires a record on the name _atproto.user.example.com, whose value begins did= and gives the full DID – or an HTTPS endpoint served at the path /.well-known/atproto-did on the handle’s domain. The specification calls the DNS method the recommended and preferred route for individuals, and describes the HTTPS route as intended for large web services that cannot automate millions of DNS records.
The specification also states the safeguard, and it is the part everyone skips: a handle should not be trusted or considered valid until the DID is also resolved and the current DID document is confirmed to link back to the handle. The link has to hold in both directions, the documentation says, because otherwise anybody could create handle aliases pointing at third-party accounts. A screenshot of a handle proves nothing on its own. The two-way check is what makes it evidence.
Now the limits, because this is where confident people go wrong. A verified domain handle demonstrates that whoever controls that account also controlled that domain name at the moment the check ran. It does not establish who the person is. If the handle is a subdomain issued by a hosting service, it says nothing at all beyond “this account is hosted there”. If the domain belongs to an organization, its registration record is often informative and is an ordinary public-records lookup. If it belongs to an individual, the registration record usually resolves to a privacy or proxy service rather than a person – that is the norm across the industry, not an obstacle someone erected specifically to hide from you. And a domain can be sold; control today is not control last year.
Mastodon’s version of the same idea
Mastodon’s user documentation opens its section on the subject with a sentence worth quoting for its candor: document-based verification and blue ticks are not possible without a central authority. There is no such authority, so Mastodon does something else. If you put an HTTPS link in your profile metadata, the software fetches the page at that link and looks for a link back to your profile carrying the attribute rel="me". If it finds one, a checkmark appears next to that link – meaning you are confirmed as the owner of the linked page, and meaning nothing else.
The validation rules are narrow and are published: the profile field’s value must be an HTTPS link, and plain HTTP links are not processed at all because they are insecure and can be modified in transit. Since version 4.0 the hostname must survive international-domain-name normalization unchanged, a rule Mastodon’s documentation explains as a defense against homograph attacks – the trick of substituting a Cyrillic character that looks identical to a Latin one so that a fake domain reads correctly to the eye. That is a well-designed check against a specific deception, and it is worth knowing exists when you are staring at a profile trying to decide whether it is who it claims.
Put the two together and you have the same underlying fact in two costumes: on both networks, the only self-declared identity signal that carries real weight is control of a domain name, and control of a domain name is a claim about an internet resource rather than about a human being. It is a lawful starting point for a records question. It is not an identification, and anyone selling it to you as one is overselling.
What each network publishes, and who holds the rest
The left column is visible to anyone. The right two columns are where the two networks stop resembling each other.
| The thing you want | Bluesky and the AT Protocol | Mastodon and the wider fediverse |
|---|---|---|
| The name on the account | A handle, which is a DNS name. It can be changed, and the account survives the change | A username plus the server’s domain. Changing servers means a new address, with a redirect the user sets up |
| The permanent identifier | A DID, described in the specification as the stable, canonical identifier that should never change Published | None equivalent. Identity is tied to the server the account lives on |
| Where the account’s data sits | Named in the DID document as the URL of the user’s data server. May be a hosting service, may be the account holder’s own machine | The one server the account was created on. Every other server holds copies of public posts only |
| Who could hold identifying records | Whoever operates that data server, plus the app service the person used | The operator of the home server, who may be a company, a collective, or one individual |
| The lawful public identity signal | A custom-domain handle, confirmed in both directions between handle and DID document | A profile link showing a verified checkmark, proved by a matching rel="me" link on the linked page |
| Reach of a moderation decision | Labels and takedowns applied by the service doing the moderating, which is not necessarily the account’s host | Local only. The documentation states an admin on one server cannot affect a user on another, only the local copy |
| What a report to the network gets you | Action against the account or the content, sometimes quickly. What it never gets you is a name. On both networks the report goes to moderators, and moderators are not in the business of disclosing subscriber information to the person who filed the report. Treat the report as the route to stopping something, and treat identity as a separate question with a different and slower answer. | |
One row above deserves emphasis because it changes what a victim should expect. Mastodon’s moderation documentation states that moderation is always applied locally – as seen from the particular server – and that an administrator or moderator on one server cannot affect a user on another; they can only affect the local copy on their own machine. Even the heaviest instrument available, suspending an entire remote server, is described as removing all content from that server locally except usernames. That is a local remedy with a local effect, and it is the correct instrument for a great many problems. It is not a delete button for the network.
A copy is not a clue: what federation does and does not spread
Copies of a post travel widely. Nothing about who wrote it travels with them. Confusing the two costs people time and money.
When an account with followers elsewhere publishes something, the post is delivered to every server those followers are on, and stored there. The author did not choose those servers and in most cases has never heard of them. This has three consequences that people routinely get backwards.
First, on removal. If the home server deletes a post, a deletion instruction goes out, but whether a given remote server acts on it depends on that server being reachable, running, and willing. A post can therefore persist somewhere after it has vanished from where it started. This is genuinely useful to understand if what you actually need is for something to stop being visible in the places that matter to you, rather than everywhere in the abstract.
Second, on preservation. The mirror image is the reason to move quickly. If a post is the thing you may eventually need to prove, capture it yourself now, in full – the complete handle including the server domain, the post’s own address, the timestamp, and the surrounding thread – rather than trusting that a copy will still be somewhere when you need it. Evidence you hold is evidence; evidence you assume exists on somebody else’s machine is a hope.
Third, and most importantly, on identity. A remote server that received a copy of a post received the post and the publishing account’s public profile. It did not receive the email address that account signed up with, or the addresses it connects from, or anything else the home server holds. The copies multiply the content and not the identity. Every so often somebody works out that a post exists on dozens of servers and concludes there are dozens of places to ask. There are dozens of places to ask about the copy. There is one place that ever held the account.
There is a fourth thing worth knowing, and it is the one that most affects timing in a case where somebody’s safety is in play. Mastodon’s moderation documentation states that since version 3.5.0, default user moderation decisions notify the affected user by email, and that the user can submit one appeal within 20 days of the decision. Read that as a practical fact rather than a criticism: a moderation action is, by default, a notification to the account it was taken against. If you are in a situation where the account learning that you complained would escalate matters, that is a fact to weigh before you file, and a reason to talk to an advocate or to law enforcement about sequence first. We keep the wider version of that discussion on our page about documenting a stalking or harassment pattern properly.
Serving process on a network that may have no company in it
The statute is a smaller obstacle than people think. The harder question here, and the one no centralized platform ever poses, is who the respondent would even be.
Take the two legal points briefly, because they are the same on every platform and our companion guide to identifying the person behind a Threads profile works through them at length against a single corporate custodian. First, section 2702 of title 18 bars a provider from divulging the contents of a communication to anyone, which is why nobody will ever send you somebody’s messages – but its bar on non-content subscriber records is written only against governmental entities, and subsection (c), at paragraph (6), expressly permits disclosure of those records “to any person other than a governmental entity.” The statute permits what the support desk says it forbids; it simply does not require it. Second, where a court is asked to compel disclosure instead, anonymous speech carries First Amendment protection: Doe v. Cahill (Del. 2005) requires a defamation plaintiff to make reasonable efforts to notify the speaker, give them an opportunity to respond, and put forward evidence sufficient to survive a motion for summary judgment before the identity is disclosed, and Dendrite International v. Doe No. 3 (N.J. App. Div.) reaches a comparable structure that many courts have since adopted or varied. The strength of the underlying claim is what unlocks identity, so the claim is what to spend money on first.
One threshold question, though, is peculiar to this network and the statute cannot settle it for you. Those prohibitions are written for a provider of electronic communication service to the public. Whether an invitation-only server run by one person for a private community is such a provider is a question for a lawyer, not for a records-research firm, and we will not pronounce on it. It is a fair illustration of why the fediverse resists confident answers where a centralized platform gives easy ones.
Who you would actually be serving, and how you find out
Here is the question a Meta or an X matter never has to ask, and this one always does: who is the respondent? On a centralized service the custodian is a named company with a registered agent, a published legal-process address and a documented procedure, and an attorney can address a subpoena on day one. On this network the only party that ever held identity is whoever runs the account’s personal data server or its home instance, and that is a fact somebody has to establish before any process has an addressee. The DID document is where you establish it: resolve the account’s decentralized identifier and the document names the service endpoint, which is the host that holds the signup email and the connection addresses. Nothing else in the network ever had them.
What you find at the other end comes in three shapes, and they are not interchangeable. The first is a company operating a large data server or a large instance, which will have terms, a privacy policy, an abuse contact and often a published law-enforcement procedure – Bluesky’s own privacy policy, for example, states that it may access, preserve and disclose stored information where it believes in good faith that doing so is required or appropriate to comply with law enforcement, regulatory or national security requests and legal process, giving a court order or subpoena as its examples, and states separately that it retains data on a valid legal request such as a preservation request or a search warrant. The second is a nonprofit or a volunteer association running an instance for a community, which may have exactly one person handling abuse, legal and hosting, and no procedure written down anywhere. The third is the self-hosted case – a did:web identifier or a single-user instance – where the data host and the subject of your request are the same party. Identify that third shape early, because a preservation request sent to it is a notification to the person you are asking about, and there is no neutral party in the middle to absorb it.
Two further facts change the arithmetic before anyone spends money. An operator outside the United States may have no domestic entity to serve at all, which turns the exercise into a jurisdiction question and sometimes a treaty question that has to be answered before a subpoena is worth drafting. And a subpoena has to issue from a filed case: where the defendant is not yet named, the ordinary sequence requires the plaintiff to plead a Doe and ask the court’s permission to take discovery ahead of the normal schedule. Both are reasons the sequence runs claim first, custodian second, identity last.
What can be done lawfully from public material is narrower than people hope and more useful than they expect. Resolving a DID document, reading a server’s published about page, its terms, its privacy policy and its stated abuse and legal contacts is ordinary public-record research: it establishes who the custodian says it is, what it says it retains, how long, and whom process should be addressed to – which is precisely what an attorney needs before drafting anything, and precisely what most people are missing when they call a lawyer and get quoted for a discovery fight nobody can aim yet. It does not identify the account holder, and we do not attempt to. Drafting, issuing and serving the process itself is the practice of law and we do none of it.
On the criminal side, a federated network is not outside federal reach merely because the software is decentralized. Section 2261A of title 18 reaches a person who, with intent to kill, injure, harass, intimidate or place another under surveillance with such intent, uses any interactive computer service or electronic communication service of interstate commerce to engage in a course of conduct that places someone in reasonable fear of death or serious bodily injury, or that causes or would reasonably be expected to cause substantial emotional distress. Whether a particular set of facts meets that standard is a prosecutor’s judgment, not ours. But architecture is not a defense, which is why the law-enforcement route is a real route rather than a formality. Internet crime can be reported to the FBI’s Internet Crime Complaint Center, and a local police report remains the document that most other doors open with.
Where people usually are when they land on this page
The right next move is different in each of these, and in two of them the right next move is to stop.
An account is targeting you and will not stop
Preserve first, report to both servers second, police third. Identity is a later question and, in most of these, one the police answer rather than you.
Counsel has filed and needs the right respondent
Working out which entity operates the data server named in a DID document, or who is behind a given Mastodon domain, is records work. That part we do.
An account is impersonating you or your organization
This one has a genuine self-help path, because the domain-handle and verified-link mechanisms let you make your own account provably yours.
You need to know which company to write to at all
The commonest request we get. It is a lookup and a corporate-records question, and it ends with an entity and an address, not with a person.
You are certain you know who it is
Then the risk is confirmation, not discovery. Being nearly right about an anonymous account has ended careers, and the person wrongly named has no way to undo it.
Someone left you and you found their new account
We decline this, in every form it arrives in. The section below explains why that refusal is not negotiable and does not depend on how the request is framed.
First moves that keep the evidence, in the order that preserves it
None of these steps identify anybody. Each of them protects the position of somebody who may later need to.
Capture it as it stands, today
Full-page captures showing the complete handle with its server domain, the post’s own address, the visible timestamp, and the thread around it. Keep the originals unedited and note the date and time you captured them.
Report on the network, and forward it
On Mastodon the report goes to your own server’s moderators, and the documentation notes you can attach the offending posts and choose to forward it to the remote server’s moderators as well. Do both. On Bluesky, use the in-app report path.
Put it in front of someone with authority
A local police report, and a complaint to the federal internet crime center where the conduct crosses state lines. These are the parties who can lawfully pursue identity, and their file is the one that later carries weight.
Hand the technical picture to counsel
If a claim is being filed, an attorney needs to know which entity holds what, and where. That is the point at which our research is useful and the point at which the legal decisions become theirs.
What we take on here, and what we turn down
This is a subject where the wrong kind of competence does real harm, so the limits are set out before the offer.
Our work on a fediverse matter is deliberately narrow and it is all records work. We establish which legal entity stands behind a given service or domain, where that entity is registered and who may lawfully be served on its behalf, whether a domain used as a handle belongs to an organization with a public trail or to a proxy, and what a specific server has actually published about its own rules and retention. The output is a written picture of the holders, with sources, that an attorney or an investigating officer can act on. It is the same public-records discipline behind the location work we do in ordinary matters, applied to an unfamiliar map.
We publish no technique for unmasking an anonymous account and we will not run one privately either. No correlating an account against other accounts, no analysis of what an account has posted in order to place its author, no cross-platform matching walkthrough, no timing studies, no attempt to work out a person from the shape of their writing. That is a refusal on principle and not a gap in ability: those methods produce a confident answer that is sometimes wrong, and the person they are wrong about pays the entire price. If the question is genuinely who someone is, the correct instrument is lawful process aimed at a real holder, tested by a court, with the account holder given the chance to be heard – which is exactly what the constitutional standards described above are for.
We are not private investigators, no one at this firm is licensed as one in any state, and we never imply otherwise. People Locator Skip Tracing is a skip tracing and public records research firm. Surveillance, interviewing a subject, and the rest of the licensed-investigator toolkit sit outside what we do and outside anything this page recommends. Every file opens with a stated lawful purpose recorded before research starts, and a purpose that does not survive being read back plainly does not become a file.
We do not pretext, ever. No one from this firm contacts a server operator pretending to be a lawyer, a police officer, an abuse desk, or a member of that community, and no one contacts the account in question under a made-up identity to draw information out of them. Small servers are run by people who answer their own mail; deceiving them would be trading on exactly the trust that makes those communities function. In the same spirit, we do not obtain private message contents, email inbox contents, account balances, financial statements, or device location. None of that is a public record, and a firm that advertises it is advertising a crime rather than a capability.
Nothing this firm writes is a consumer report, and the Fair Credit Reporting Act is why that distinction matters to you. We are not a consumer reporting agency and are not regulated as one, so our files carry none of the accuracy, notice, and dispute machinery that statute builds around decisions that shape somebody’s life. Our work therefore must not be used – not partly, not as a cross-check, not as background color – where the question is whether to extend a person credit or insurance, hire them, rent to them, or grant them a license or a public benefit. Those calls belong with an agency licensed to make them. And an anonymous account is a uniquely poor reason to open that door, since whatever it asserts about somebody is unverified by construction.
Pseudonymity on these networks is very often a safety measure, and we treat it that way. A large share of the people who moved to Mastodon or Bluesky under a name that is not theirs did so after leaving someone, after being found once already, or because being publicly identifiable would cost them a job, a family, or worse. That is not evasion and we will not describe it as such; people are entitled to live and speak without being cataloged by strangers. So we decline outright any request to identify or locate an account holder where the requester is, or may be, a former partner, a family member the person has withdrawn from, or anyone subject to a protective order – and we decline it however the request is dressed: as a debt, as a service of process, as concern for a child, as a business matter. Where a request touches somebody who has separated from the person asking, intake tightens rather than relaxes, and we would sooner lose a legitimate client than be the reason someone is found. If you are the person being sought and you believe research is being run on you, most states operate an Address Confidentiality Program for exactly this situation, and a local advocate can tell you how it works where you live.
Everything on this page is general information about how these networks and these statutes are written. It is not legal advice, it is not an assessment of your particular situation, and reading it puts no professional relationship in place. Software changes, servers close, policies are rewritten, and courts refine these standards case by case. If a claim is on the table or somebody’s safety is in question, take this page to an attorney or an advocate rather than acting on it alone.
Who asks us about a fediverse account
Six starting points, one deliverable: a map of who holds what, handed to someone with the authority to use it.
People being harassed
Needing the report routed properly
Litigation counsel
Identifying the right respondent
Trademark owners
Chasing an impersonating handle
Newsroom desks
Testing whether a source is who they say
Victim advocates
Timing a report around a safety plan
Compliance teams
Preserving a record before it moves
What separates these from the requests we turn away is not their subject but their destination. In each of them the answer goes to a court, a regulator, an editor, or an investigating officer – somebody with a duty to test it and a procedure for being wrong. When the answer would go nowhere except to the person asking, that is the tell, and it is where we stop. If your question is closer to auditing your own exposure than to identifying somebody else’s, our page on finding accounts set up in your name is the more useful starting point.
Told before you pay, not after
Plenty of fediverse questions have no findable answer, and we would rather say so at the inquiry stage than bill for the discovery. If the server you are asking about publishes nothing, is registered behind a proxy, and has no reachable operator, that assessment costs you nothing and takes a short conversation. When there is something to find, you get the holders, the sources, and the reasoning in writing.
Questions we get about pseudonymous accounts
Can you just tell me who is behind a Mastodon account?
No. We do not take identification work on anonymous accounts and we publish no method for it. The records that could bear on it sit with the operator of the single server the account was created on, that operator owes a stranger nothing, and the lawful way to reach them is a court-supervised process run by an attorney with a filed matter. What we can establish is who that operator is as a legal entity, where they are, and what they have published about their own rules – which is the piece an attorney or an officer actually needs and the piece that is genuinely hard to find.
Does a subpoena work on Mastodon, and who would it even go to?
There is no central company, so a subpoena has to be aimed at a specific holder: the operator of the home server the account lives on, identified as a legal person or business rather than as a domain name. Whether that party is within the issuing court’s reach, whether they retained anything, and whether they will respond at all varies enormously – some servers are companies with counsel, others are one person and a rented machine abroad. Establishing which of those you are dealing with, before anyone spends money on process, is the useful first step and it is a records question rather than a legal one.
What does a custom-domain handle on Bluesky actually prove?
That whoever controls the account also controlled that domain name when the check ran, and that is all. The protocol confirms it either through a DNS TXT record at the _atproto sub-domain of the handle, whose value begins with did= and names the account’s identifier, or through a file served at /.well-known/atproto-did on that domain. The specification is explicit that a handle should not be trusted until the identifier is resolved and the identifier’s document is confirmed to link back to the handle, in both directions. If the handle is just a subdomain the hosting service issued, it proves only where the account is hosted.
What does the checkmark next to a link on a Mastodon profile mean?
It means the page at that link contains a link back to the profile carrying a rel=”me” attribute, so the profile owner has demonstrated control of that page. Mastodon’s documentation is refreshingly blunt that document-based verification and blue ticks are not possible without a central authority, and this is the substitute. The rules are narrow: the link must be HTTPS, plain HTTP is not processed because it can be altered in transit, and since version 4.0 the hostname must survive international-domain-name normalization unchanged, which is a guard against lookalike characters in a fake domain. The checkmark verifies the link, not the human.
Can the person running the server see my address and my messages?
Assume the operator of the machine can see what is stored on the machine. Mastodon’s administrator documentation describes sign-up as requiring a confirmed email address, describes sign-ups as rate-limited by network address, and gives moderators an IP Rules page for blocking individual addresses or whole ranges – a system that does those things is a system that handles those details. What any given operator retains, for how long, and who else can see it is set by that operator, and the only reliable way to know is to read what that specific server publishes about itself before you rely on it.
Can I get a post removed from the whole network?
Generally no, and this is the most commonly misunderstood point about federation. Mastodon’s documentation states that moderation is always applied locally and that an administrator or moderator on one server cannot affect a user on another – they can only affect the local copy on their own server. When a post is deleted at its origin a deletion instruction propagates, but whether a given remote server acts on it depends on that server being online and cooperative. Aim for removal in the places that matter to you, capture your evidence before anything moves, and treat a network-wide erasure as something no one can promise.
Is federal privacy law the reason nobody will tell me anything?
Not exactly, and the difference matters. Section 2702 of title 18 bars a provider from divulging the contents of communications to anyone, which is why no one will send you messages. But its bar on non-content subscriber records is written against governmental entities, and subsection (c) expressly allows a provider to divulge those records to any person other than a governmental entity. The statute permits disclosure to a private party; it does not require it. What actually stops it is the operator’s own policy and risk appetite, and where a court is asked to compel it instead, a First Amendment test that puts the strength of your underlying claim at the center.
Someone anonymous is harassing me. What should I do first?
Capture the evidence before you do anything that might cause it to disappear: full handles including server domains, post addresses, timestamps, and the surrounding thread, saved unedited. Then report on the network, forwarding the report to the remote server’s moderators as well as your own. Then file with local police, and with the federal internet crime center if the conduct crosses state lines. Before you file, weigh one timing fact: Mastodon’s documentation states that default moderation decisions notify the affected user by email, with a twenty-day appeal window – so if being seen to complain would escalate your situation, speak to a victim advocate about sequence first.
Find out who holds the record before you spend a dollar on process
Send us the handle and the server domain and we will tell you what entity stands behind them, whether there is a reachable operator, and whether the picture is one an attorney can work with. If it is a dead end we will say so at the start. Still unsure the question is the right one? Ask a researcher directly and you will know within 24 hours whether the work is worth doing at all.
Get the holder map
