Pleroma Media Ownership: What It Actually Means
If you are running a Pleroma instance or just posting content on the Fediverse generally, understanding media ownership matters more than people realize. I ran into this the hard way when someone mirrored content from my instance to another server and stripped the attribution in the process. Here is how ownership actually works on Pleroma. When you upload media to a Pleroma instance, the media file itself gets stored on that server. The instance admin has physical custody of the file. But custody is not the same as ownership. You, the uploader, retain the copyright to the content you created. The instance terms of service typically grant the server a license to store, serve, and relay that media through the federation system. This is standard across pretty much every Fediverse platform, not just Pleroma specifically. What trips people up is the difference between the file and the post metadata. When a toot with media gets federated out, the other instances receive both the media attachment and the associated activitypub data. That activitypub payload contains the original URL of the media, which points back to your instance. If that other server downloads and rehost the image, they are making a copy. The original still lives on your server with its original URL intact.
I discovered a weird edge case a while back where an instance running an older version of Pleroma would fetch media using the remote URL but then rewrite it to point at their own storage path in the database. When you checked the media info endpoint on my instance, everything looked correct, but on their end the ownership chain was broken. Their UI would show the content as if it originated locally. There was no straightforward way to detect this from the receiving side without manually checking the original ActivityPub object. The workaround I used was checking the first_activity field in the media metadata directly, rather than relying on the display URL which could be spoofed through their rehosting pipeline. It takes about 10 seconds per check and saved me from getting confused about a whole batch of imported posts.
Technical Details You Need to Know
Pleroma stores media in its uploads directory, which by default lives under the instance root. The database tracks each file with a UUID, the original filename, the uploader account ID, and the remote URI if the file was pulled from elsewhere. The key field for ownership tracking is the account_id column on the media table. That is your anchor. If you ever need to prove you uploaded something, that record is what you reference. The media also gets assigned a public_url and an secret_url. The public_url is what gets embedded in toots and federated out. The secret_url is for internal operations and moderation tools. Neither of these determines ownership, but they are relevant when you are dealing with privacy violations or DMCA requests. If someone posts your content to their instance and then deletes it there, the public_url on their server stops resolving, but the original remains untouched on your instance.
Get the Full Details
Common Misunderstandings About Media Rights
Many users assume that because Pleroma is open source, media on their instance becomes public domain or freely usable by anyone. That is incorrect. The software being open source does not change copyright law. Your content remains under your copyright unless you explicitly license it differently. Some instances have different policies around reposts and whether they consider rehosting without permission to be acceptable practice. Pleroma itself does not enforce this at the protocol level because ActivityPub has no built-in ownership enforcement mechanism. It is all social convention and individual instance policy. Another thing nobody mentions is that media thumbnails get generated separately from the original file. Pleroma creates resized versions for previews. Those thumbnails are stored in the same directory structure and are tracked in the database, but they are not independent works. They derive from the original upload and carry the same ownership metadata. If you remove the original, the thumbnail usually gets cleaned up automatically by the garbage collector, assuming your instance has media cleanup enabled, which most do by default.
What Happens When You Leave an Instance
This is where things get messy. If you create an account on a Pleroma instance and then decide to move to a different server, your toots and media stay behind. The Fediverse does not have a content migration feature that works reliably across platforms. You can export your data through the settings page, but that gives you a JSON activity stream and a zip of your uploads. The federated copies that other instances made of your media are out of your control. Some administrators will honor takedown requests for cached content. Most will not, especially if the content has been rehosted across multiple servers. I lost track of roughly two hundred images from my old instance after switching. None of them were particularly sensitive, but it bothered me that I had no way to verify whether any of them were still being displayed somewhere without manual searching. The only practical solution is to assume anything you post federates permanently. That is the reality of distributed social media. There is no central authority to contact, no bulk removal tool, and no protocol-level recall mechanism.
Checking Your Own Media Ownership
If you want to verify what media you have uploaded and who currently has access to it, you can query the Pleroma API directly. The /api/v1/media endpoint returns a paginated list of your uploaded files with their IDs, URLs, and timestamps. The /api/v1/media/{id} endpoint gives you the full metadata including the activitypub URI and any remote instances that have fetched it. This is useful if you need to document something for a support request or legal matter. Instance administrators have access to the admin dashboard where they can see all media across all users. This is administrative tooling, not ownership transfer. Being able to view or moderate media does not make the admin the owner. That distinction matters when instances get into disputes about content or when servers get shut down and their data ends up in archival projects. Pleroma itself is developed by the Pleroma team and various contributors on GitLab. The media ownership model is baked into the ActivityPub specification, not something unique to Pleroma. If you are looking for more details on the technical side, the source code for how media is handled lives in the Pleroma repository on GitLab under the lib/pleroma/web/activity_pub directory and the upload-related modules. The documentation on their wiki covers the API endpoints as well.
