foxyoreos (they/them, commissions open)
@foxyoreos.bsky.social
640 followers 120 following 7K posts
Furry vore artist, very NSFW. Follow my other galleries, I don't trust this site's direction: https://aryion.com/g4/blog.php?id=80848 Support: https://subscribestar.adult/foxyoreos Commissions: https://foxyoreos.netlify.app
Posts Media Videos Starter Packs
foxyoreos.bsky.social
This is not really being treated like a first-class experience, and there's a lot of UI and client design (and even protocol design!) that could make things a lot better I think that the Bluesky devs have just never thought about, because (imo) they aren't thinking of this use-case.
foxyoreos.bsky.social
Now Bluesky *does* support having multiple accounts, sure.

..........on the same appview.

The official client doesn't have an ability to link an account that's going through a different appview. And the devs have said this will probably never come to mobile.
foxyoreos.bsky.social
I think data sovereignty is only a very, very small part of the risk analysis that marginalized communities will need to start doing when making decisions about this stuff.

Which does not mean having an *ability* to share identity is bad, it's not! But I wouldn't myself make it the default.
foxyoreos.bsky.social
If a bunch of my data is scoped under one account, migrating the data might be the least of my concern. Doxing might be a larger risk, getting banned from a payment processor might be a larger risk.

You bring up Reddit - policing bans on Reddit communities based on other subscriptions was common.
foxyoreos.bsky.social
Eh.. I mean.. I dunno.

I can think of risks. Suppose you need to start splitting data across multiple PDSes, or app views start crawling other lexicons?

(note that this is not theoretical, services like Patreon already scrape siloed servers for disallowed NSFW content).
foxyoreos.bsky.social
And in particular we have data sources that can be reused..... until we get visibility controls and access controls.

Which we know are eventually coming to ATProto - and maybe the devs have thought about the impact that will have on shared lexicons? But.. I don't have the MOST confidence in that.
foxyoreos.bsky.social
I also do think reusing the data and having data sources and raw access to the data is *really* really good. HUGE win <3

But are we talking about federation at that point, or are we talking about a data format and/or an API?
foxyoreos.bsky.social
ActivityPub again, also kind of suffers from the same problem. There's no real affordance outside of clients for using multiple accounts, it's assumed you'd have one profile description/pic that gets shown to every server that you federate with.

This all feels very disconnected from reality for me.
foxyoreos.bsky.social
I think ATProto critters assume that "of course you'd want everything linked to one domain", and like..

..that's just not really the case for most NSFW artists I think? Account separation is a huge use case that the devs on Bluesky don't understand, so the protocol is designed for the opposite.
foxyoreos.bsky.social
This is another example where the protocol design is not really solving my problems in a serious way? And is largely focused in on solutions that I'm not sure I actually want - like I'm not sure I do want all of my accounts linked to one identity, that's a failure point.
foxyoreos.bsky.social
Like, what makes this so useful is it just works with every site that participates. They don't need infrastructure, they don't need a PDS, they don't need anything.

They can just link your account through one line of HTML.

It's great! Just.. not really anything to do with ActivityPub.
foxyoreos.bsky.social
Like you can go through a validation service that they run for large accounts. Or you can buy a domain.

On Mastodon, I can verify that I own a Furaffinity account, and it'll get displayed in the UI.

This is pretty fucking neat, and also has nothing to do with federation or the protocol.
foxyoreos.bsky.social
What I see as necessary here is a way for identities to cross-validate with each other in a way that is heavily transparent to end users. And there are mechanisms for that!

This is one of the things I'll actually praise Mastodon on, it does pretty well. Bluesky has.. not really thought about it.
foxyoreos.bsky.social
> the shared identity is the important part that is missing in fedi, but atproto has this

See, this is also a thing that I want to question.

IS a shared identity good? Like, critters have been asking for circles and making multiple accounts on here to post things since the network began.
foxyoreos.bsky.social
But that's likely a future concern, at least for right now being able to serve posts to Bluesky users from a static server without an account is a pretty strong advantage.
foxyoreos.bsky.social
Okay, I DO see that as a major advantage.

Although I worry that this will become less true as PDSes mature and networks start to go the same way as email and block out ranges of PDSes, or demand authentication from them to prove that they aren't spam/scammers.
foxyoreos.bsky.social
And none of them will be able to talk to each other except through Bluesky's lexicon, which is only being applied to a subset of their posts? I don't see how that scales.
foxyoreos.bsky.social
I don't see a lot of planning on the ATProto side for dealing with actual fragmentation - I don't think critters have thought about what the actual end-game of all of this is. You have to imagine for every theoretical third-party server you propose, there's actually gonna be 50 of them.
foxyoreos.bsky.social
The only thing a protocol can do is try to mitigate the downsides.

The problem with ATProto (and ActivityPub) design is that the mitigations seem really primitive and I'm left wondering if all of this wouldn't be solved better by using Postybirb and building a halfway decent multi-account client.
foxyoreos.bsky.social
Like we're kind of circling around an unavoidable problem here which is that *you are going to have a partial view of the network.*

You just are. You will have either partial fragmentation, like on the fediverse, or full fragmentation, like with the solution you propose.
foxyoreos.bsky.social
If a quarter of my followers go to your server, a quarter go to Northsky, and half stay on Bluesky, and all of them start making siloed posts, is there a mechanism in ATPro for me to handle this from one account?

No. ATProto devs have not even begun to approach that problem.
foxyoreos.bsky.social
And so a lot of the innovation of a protocol needs to be about handling the really thorny problems inherent here. Like, if I migrate an account to your server, will my followers get notified? On Bluesky, no! They'll just start missing posts.

I'm back in the Fediverse again.
foxyoreos.bsky.social
The way I see it, fragmentation is inevitable - there is no such thing as a federated system with a global view of the network - not because the tech doesn't exist but because conceptually it just doesn't make sense.

Not without some kind of major innovation that bsky devs aren't thinking about.
foxyoreos.bsky.social
I make multiple accounts on Northsky, your server, Blacksky, etc..

And that could work! Especially if there's a client that allows easy account switching.

But then I start to ask.. "couldn't I also do that with Bluesky too? Why have the federation at all?"
foxyoreos.bsky.social
We have a bunch of silos and one main app view (Bluesky).

With your system, if users spread to a bunch of different silos, I'm back into the same position where I started from. I can still get my posts showing up on Bluesky, but a lot of my art will only be visible on my current silo.

Unless...