I recently edited a post that had a source that started with at:// . Doing a search , this style of source started showing up about 11 days ago - mid-August, 2023. I haven't looked at all of them, but the ones I've seen seem to be related to Bluesky.

They seem to be of the form: at://did:plc:[hash1]/app.bsky.feed.post/[hash2]

There are at least a couple of artists that have more than one image here with this style of source, and for those two artists, the [hash1] part is the same. The [hash2] part varies per post.

Desktop Firefox has no idea what to do with these sources - they're not even clickable. It also doesn't appear to be a common URL scheme, per Wikipedia. That article mentions "mobile deep linking", which basically means that some apps make up URL schemes so you can link directly to a certain place inside the app.

If you have the Bluesky app installed on a mobile device, you navigate to e621 in a mobile browser, and you click on an at:// link here, will that open up the app and take you directly to that post on Bluesky? If that's how it works, then there's probably some value to keeping those links as sources here on e621.

Is there any way to transform an at:// link to a https:// link that can be viewed with a normal Web browser from anywhere?

I have the mobile app and the URL doesn't even seem to do anything, even if I construct an actual clickable link for it. If I use the "Share" function from within the app, it creates a normal URL rather than this - so I'm not sure what these people are doing.

post #4247954

This one had the source at://did:plc:fn5kv3xek2gi5tcjpxbiqs36/app.bsky.feed.post/3k5kdzotzm22o - the [hash1] seems to be some sort of account identifier(?) while [hash2] actually refers to the post. Since I knew this post was by kolae, I could easily find the actual http source by combining the known username and [hash2] to find the source URL: https://bsky.app/profile/kolae.bsky.social/post/3k5kdzotzm22o. Unlike Twitter, the username actually needs to be correct for the URL to work. See https://bsky.app/profile/xxxxx.bsky.social/post/3k5kdzotzm22o not working.

If you don't know the username however? I guess that's going to be tougher. I imagine there's some way of resolving hash -> username in the API, but I haven't had the chance to play around with the API yet. If I figure it out I'll make a bot that automatically corrects at:// links to the valid counterpart.

Uh, shouldn't we DM the folks who added those sources and just ask them what the fuck they did to even generate it?

It's because of the Postybirb app, someone should report that issue to the developers. I was wondering why all the posts with one of these were uploaded by an artist.

votp said:
Uh, shouldn't we DM the folks who added those sources and just ask them what the fuck they did to even generate it?

No needs to, I did it alredy.

I've started to resolve these into URLs - so please don't just go on a spree of nuking them from the source fields.

----

votp said:
Uh, shouldn't we DM the folks who added those sources and just ask them what the fuck they did to even generate it?

Sometimes I overlook this as an option, usually because the end user has no clue what they're doing and can't provide any meaningful information, but probably should've done it nonetheless.

wolfmanfur said:
It's because of the Postybirb app, someone should report that issue to the developers. I was wondering why all the posts with one of these were uploaded by an artist.

Good to know. I'll file a bug report, if nobody has already.

faucet said:
please don't just go on a spree of nuking them from the source fields.

I haven't changed anything on the posts that had these sources. I just noticed it happening, and reported it here in the forum.

I'll file a bug report, if nobody has already.

I previously wrote topic #35880 and topic #35890 about two similar issues (blob: and file: URLs), but I don't think either of them has made it to a Github issue yet. It seems like if you wanted to also disallow at: URLs, that would go right next to those two in the code.

(Reading this again, maybe you meant a Postybirb bug report, instead of an e621 one. However, if the version of Postybirb that creates at: sources is in the wild, and it's thought that it may be in use for a while, then it might be good to fix it on the e621 end as well.)

edit: another possibility

kora_viridian said:
I haven't changed anything on the posts that had these sources. I just noticed it happening, and reported it here in the forum.

Don't worry, I wasn't referring to you with that :P

kora_viridian said:
(Reading this again, maybe you meant a Postybirb bug report, instead of an e621 one. However, if the version of Postybirb that creates at: sources is in the wild, and it's thought that it may be in use for a while, then it might be good to fix it on the e621 end as well.)

I made a post in Postybirb's bug reports channel and it got no attention so far, it's not actually exclusive to e621, the same URIs show in their own dashboard panel which are also just as useless in that situation. I'll probably make a GitHub issue with Postybirb later.

I don't think fixing it from the e621 end is really an option. The at URIs actually contain information that can be used to get a source URL unlike blob or file, but Earlopain already stated somewhere that we don't want any source manipulation that relies on making external API calls.

For now I'll keep resolving them myself, if it continues to remain a problem I'll probably just fully automate the task and release the bot on GitHub or something.

faucet said:
I'll probably make a GitHub issue with Postybirb later.

I feel like Postybirb probably has a unity bus factor, so a GitHub issue might make it more visible to those who can do something about it. :)

I don't think fixing it from the e621 end is really an option. The at URIs actually contain information that can be used to get a source URL unlike blob or file, but Earlopain already stated somewhere that we don't want any source manipulation that relies on making external API calls.

My idea of "fix from e621 end" was mostly "disallow it as a source on e621". I'm not sure if e621 currently has that capability, but I kind of suspect it doesn't. I can understand Earlopain's position; anything that's automated into e621's code base and relies on external APIs can potentially break if access to those APIs goes away or becomes expensive.

edit: clarified

kora_viridian said:
I feel like Postybirb probably has a unity bus factor, so a GitHub issue might make it more visible to those who can do something about it. :)

My idea of "fix from e621 end" was mostly "disallow it as a source on e621". I'm not sure if e621 currently has that capability, but I kind of suspect it doesn't. I can understand Earlopain's position; anything that's automated into e621's code base and relies on external APIs can potentially break if access to those APIs goes away or becomes expensive.

edit: clarified

This is like adding URLs that depend on TOR or something, right? Onion links wouldn't be allowed, right? XD

alphamule said:
This is like adding URLs that depend on TOR or something, right? Onion links wouldn't be allowed, right? XD

source:*.onion*

All of them seem to be some kind of FurAffinity backup service. Using the fancy new multi-metatags, I can't find a single post that doesn't also have */fa/* in the source link somewhere:

source:*.onion* -source:*/fa/* -onion*

(You can try removing the negation on the second term if you want to confirm for yourself this is working correctly. The third term is necessary because the first term also matches FA's URL scheme for images posted by three users of that site whose account names begin with "onion", and I can't narrow it to *.onion/* because some sources use .onion.ly or perhaps other patterns for some reason instead.)

Oh fuck, is Bluesky one of those social networks that doesn't even have a real website, just a phone app? That's gonna be FUN to deal with...

alphamule said:
This is like adding URLs that depend on TOR or something, right? Onion links wouldn't be allowed, right? XD

Eh, I feel like it's acceptable in some cases. Most the time we don't want third-party sources, in the same way we don't have third-party Reddit or iFunny posts in the sources field, but some exceptions like archived_source are reasonable. According to wat, every existing Onion source is an archived source, so they're probably all valid.

I don't think requirements like needing to download Tor or use an Onion proxy is specifically a reason to not allow a source either, other sources like adult content on Fur Affinity require registering an account and there's also invite-only websites (like Bluesky) which are even harder to access than Tor.

errorist said:
Oh fuck, is Bluesky one of those social networks that doesn't even have a real website, just a phone app? That's gonna be FUN to deal with...

It does have a website, I already explained in a previous post that at://did:plc:fn5kv3xek2gi5tcjpxbiqs36/app.bsky.feed.post/3k5kdzotzm22o converts into https://bsky.app/profile/kolae.bsky.social/post/3k5kdzotzm22o which can be viewed in a nromal browser (if you have access)

faucet said:
Eh, I feel like it's acceptable in some cases. Most the time we don't want third-party sources, in the same way we don't have third-party Reddit or iFunny posts in the sources field, but some exceptions like archived_source are reasonable. According to wat, every existing Onion source is an archived source, so they're probably all valid.

I don't think requirements like needing to download Tor or use an Onion proxy is specifically a reason to not allow a source either, other sources like adult content on Fur Affinity require registering an account and there's also invite-only websites (like Bluesky) which are even harder to access than Tor.

It does have a website, I already explained in a previous post that at://did:plc:fn5kv3xek2gi5tcjpxbiqs36/app.bsky.feed.post/3k5kdzotzm22o converts into https://bsky.app/profile/kolae.bsky.social/post/3k5kdzotzm22o which can be viewed in a nromal browser (if you have access)

Oh right. At least TOR you can just access it through any browser if you have it installed on your gateway. Sites that require that you browse it from their app is Google Play levels of annoying. AliExpress was giving these weird "Unknown message type, please check it on App." messages which I assume are for some spam or thing that Ali wants you using their integrated-web-browser app for.

kora_viridian said:
My idea of "fix from e621 end" was mostly "disallow it as a source on e621". I'm not sure if e621 currently has that capability, but I kind of suspect it doesn't. I can understand Earlopain's position; anything that's automated into e621's code base and relies on external APIs can potentially break if access to those APIs goes away or becomes expensive.

I don't know if e621 disallows inputting certain sources, but the site does have the ability to automatically reformat URLs in the source field. e621 uses URL reformatting in practice for Pixiv userpage links, trimming the /en/ from the URL to resolve to the right language when visited. There is a pending pull request to add more sources to this list, automatically cleaning up URL formatting and removing potentially identifying information: https://github.com/e621ng/e621ng/pull/426

As for Bluesky, please don't use Bluesky. The maintainers are not interested in the open web, and the site has potentially worse image quality standards than Twitter. Their ToS also very aggressively states that anything you post on the platform belongs to them. I strongly recommend Itaku, Cohost, Mastodon, or any number of other alternatives instead - just don't make Twitter-but-worse the replacement of choice.

song said:
There is a pending pull request to add more sources to this list, automatically cleaning up URL formatting and removing potentially identifying information: https://github.com/e621ng/e621ng/pull/426

The final version of that PR has been pending for just over a year now. By my count, looking at the change log thread here, e621 has had 21 releases to production since then. From that, it wouldn't be hard to conclude that those changes are never going to make it to production. :)

Their ToS also very aggressively states that anything you post on the platform belongs to them.

I guess you're talking about the "in any media" part of section 2.d.ii. of Bluesky's ToS? The lead-in for section 2.d says you keep ownership and they don't own the rights, except for the license you give them, which is described in the rest of the section.

I am not a lawyer, and this is not legal advice, but this doesn't seem too different to me than a couple of other well-known sites:

Dragon Fruit Ventures, LLC said:
When you upload content to e621 via our services, you grant us a non-exclusive, worldwide, royalty-free, sublicensable, transferable right and license to use, host, store, cache, reproduce, publish, display (publicly or otherwise), perform (publicly or otherwise), distribute, transmit, downsample, convert, adapt, and create derivative works of, that content. These permissions are purely for the limited purposes of allowing us to provide our services in accordance with their functionality (hosting and display), improve them, and develop new services. These permissions do not transfer the rights of your content or allow us to create any deviations of that content outside the aforementioned purposes.

Frost Dragon Art, LLC said:
When you upload content to Fur Affinity via our services, you grant us a non-exclusive, worldwide, royalty-free, sublicensable, transferable right and license to use, host, store, cache, reproduce, publish, display (publicly or otherwise), perform (publicly or otherwise), distribute, transmit, modify, adapt, and create derivative works of, that content. These permissions are purely for the limited purposes of allowing us to provide our services in accordance with their functionality (hosting and display), improve them, and develop new services. These permissions do not transfer the rights of your content or allow us to create any deviations of that content outside the aforementioned purposes.

(Every couple of years, somebody reads the "you grant FA a license to your images" part of the FA ToS, freaks out, and a bunch of journals telling people to stop uploading to FA appear. Then, someone who might actually be a lawyer explains it, and the drama dies down again.)

New development on this, at some point between me making the bot that resolves these and now it's became possible to use the DID in the URLs, example: https://bsky.app/profile/did:plc:fn5kv3xek2gi5tcjpxbiqs36/post/3k5kdzotzm22o

These links don't look as pretty, but the identifiers are at least stable so the source links will continue to work if the user changes their username. I can also save making any API calls this way, since it just requires some basic string manipulation.

If there are no objections, I'll switch the bot from handles to DIDs. So far the bot has replaced ~582 source links, I could probably go back through these and use the DID format instead.

faucet said:
New development on this, at some point between me making the bot that resolves these and now it's became possible to use the DID in the URLs, example: https://bsky.app/profile/did:plc:fn5kv3xek2gi5tcjpxbiqs36/post/3k5kdzotzm22o

These links don't look as pretty, but the identifiers are at least stable so the source links will continue to work if the user changes their username. I can also save making any API calls this way, since it just requires some basic string manipulation.

If there are no objections, I'll switch the bot from handles to DIDs. So far the bot has replaced ~582 source links, I could probably go back through these and use the DID format instead.

Make sure to ask Bluesky if that's going to be stable and not deliberately sabotaged like Discord had to do because of hotlinking. I'm... looking at the headache of archiving 86 pages of Discord source links. :( But that's for another thread!