[tetrisgm]

Absolutely. In fact I’d love for my startup to run our own atproto instance separately from Bluesky, but it still looks like quite a lift. Lmk if you have some recommendations.

Basically our thing would give that ecosystem the ability to have personal pages that can look like Patreon, YouTube, Instagram and others

[steveklabnik]

Are you trying to run a parallel network, or build on top of the existing one? "run our own atproto instance separately from Bluesky" sounds like you want a fully parallel network, but that should be pretty rare to need or want, so I'm not sure that's what you actually mean. An "atproto instance" isn't exactly a thing.

[tetrisgm]

I’d prefer running our own thing separate from bluesky. We’d give people something like username.page.app and they’d make posts there. If people wanna follow on bluesky they can, and we provide a username that’s just the url.

I know we can do all this by just posting to Bluesky. But I want to give usernames, host the data on our end, and I’d prefer using the protocol but not be directly associated or dependent on Bluesky.

[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

[psnehanshu]

You mean you want to host the personal repositories (PDS) for your users?

[tetrisgm]

Ideally yes!

[tynanpurdy]

It depends how much you want to replicate. All you really need is the Application Data Server (or AppView) to aggregate the records you are interested in, serve them to your client app, and write them to people’s repos. I’ve been tinkering with the ‘personal website on AT’ idea space for a bit, tons of cool possibilities (and several people already have implemented cool AT integrations in their sites!). Happy to chat ab it.

[tetrisgm]

HMU! I’m “shokunin.” on discord, leshokunin on TG / Twitter.

I’d prefer running our own thing separate from bluesky. We’d give people something like username.page.app and they’d make posts there. If people wanna follow on bluesky they can, and we provide a username that’s just the url.

I know we can do all this by just posting to Bluesky. But I want to give usernames, host the data on our end, and I’d prefer using the protocol but not be directly associated or dependent on Bluesky.