[steveklabnik]

Okay, so this sounds like you'd want to run an appview + pds. (and possibly a relay, depending on some details.) Except for one thing:

> or dependent on Bluesky.

If you want to take this to an extreme, and are uncomfortable with how did:plc has not yet moved into its own org, then you'd want to also run your own plc server, etc. The problem with doing this is:

> If people wanna follow on bluesky they can

You lose this. Because you're now not running on the main atproto system, but instead a fully parallel one of your own.

Anyway, you could start on this by running a PDS via the reference implementation here: https://github.com/bluesky-social/pds and then building your own appview (application).

You could also take a look at Blacksky's implementation https://github.com/blacksky-algorithms/rsky and if you end up using it, consider throwing them a few dollars. Alternative implementations are super important!

[tetrisgm]

Thank you for the detailed answer! Totally comfortable with the did implementation. Just trying to separate from their brand and just use the standard :)

We already built our own platform independently from Bluesky, so we have a timeline in the wrong post and everything. I’m just trying to give our users into opera ability. So that when they make a post on our platform, people can also follow your Bluesky and see on their timeline. Am I correct to assume then that we would not require our own app view?

[steveklabnik]

You're welcome, yeah then that's a lot easier.

> Am I correct to assume then that we would not require our own app view?

Well, given that you have built a platform, and you then want to interact with the atproto eocsystem, that means you'd be making your platform an appview, in a sense. An appview is just a service that reads the underlying data from the network and does something useful with it.

[Kye]

There's hope for an independent but synchronized PLC directory: https://tangled.org/@microcosm.blue/Allegedly