3 ms·

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

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

tynanpurdy 1y ago
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 1y ago
  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.
steveklabnik 1y ago
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 1y ago
  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 1y ago
    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 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 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 1y ago
      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 1y ago
        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.

tynanpurdy 1y ago

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 1y ago
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.

steveklabnik 1y ago

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 1y ago
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 1y ago
  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 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 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 1y ago
    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 1y ago
      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.