With the IndieWeb version of POSSE, the source of truth is the webpage you control.
For the ATProto version of POSSE, the source of truth is the record in your PDS. That record is interesting because it is both content-addressed and signed with your private key.
Where ever that record is syndicated, the reader (or app displaying the content) should be able to demonstrably verify the authenticity of the record.
And you can host your own PDS entirely independent of Bluesky, there are several interfaces for both reading and publishing Standard.site records:
> content-addressed and signed with your private key
Technically valid but also not required. ATProto works hard to present them as valuable or needed, like added value of sorts but:
- The need for signed content is niche to specific use-cases. Not sure even news outlets need this as long as they control their domain.
- The PDS is a funny contraption of protocols and technologies that are quite complex and probably can't (usefully) exist on their own outside the "atmosphere" ... even if you manage to set one up.
The question would be, why bother with all this complexity and layers when you can self-host your website anyway.
The added value of a PDS/ATProto is to participate in the social cloud of Bluesky. Without it, the entire thing is more of an engineering showcase than a useful tool.
Neither Bluesky, nor other ATProto services require any of this.
RedDwarf is an example of an ATProto client that connects only with your PDS, uses Microcosm (https://www.microcosm.blue/ )'s aggregation index (they calculate aggregate counts for a variety of things with a couple of raspberry pis run off of a home fiber connection): https://reddwarf.app/
No big iron anywhere in the picture.
You give up the ability to search the network, but okay, that's already a feature that all Mastodon users sacrifice as well.
Does it work well? It sounds like it relies on scraping all follow relations in a central place (Microcosm) and then scrapes those feeds to find who replied to you.
On my machine, the initial state isn't simulated. It only begins simulation when I touch it. At which point, the weight causes the bottom blocks to intersect each other significantly.
If I open it, click on the background to activate the physics and just keep the tab open, pretty much all of the blocks that can collapse do eventually collapse.
One more pedantic nitpick: when a block gets wedged between two blocks at an angle, it gets slowly pushed out, although there is a lot of weight resting on the top block. That would be realistic only (maybe) if the blocks were made of ice, but not for other materials...
Nah that's just the effect of turning on the simulation. The initial version isn't the same as the first steps because there's no weight. If you look closely after you click the blocks overlap slightly.
Something similar happens all the time in games when you go from a static version of something to the higher level of detail version with physics enabled, if the transition isn't handled gracefully or early enough you can get snapping.
So, it's a term of art, and i'll even agree that it's got a bit of a tech-y pejorative lean to it, but it's in wide use, and Jarvis certainly isn't solely a person who comes from tech.
I wouldn't write ATProto off as just microblogging, there are a bunch of interesting (and exciting depending on your POV) apps out there that _aren't_ microblogging apps. To name a few:
There's still some more work to do to make the developer experience simple enough that it's a no-brainer for people to pick ATProto up in anger.
But there's a lot of work developing on that front, and the next 6-12 months will be super exciting to watch.
The longer story is that most people don't understand that ATProto is more than just Bluesky, and the usecases are wayyyyyy broader. That's going to take more time to play out in the market.
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
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.
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.
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!
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?
> 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.
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.
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.
I'd argue that ATProto is the next iteration of open internet. It's what an internet where accounts/identity and verifiable content attribution are built in, and nobody using the technology needs to think about any of that.
There's a space here where we can move from nobody having smart phones or hosting digital presences -> everyone having digital presence provided by Facebook/Instagram, and icloud/google accounts -> Accounts w/ something like ATProto where its your stuff, you get to decide where you keep it, and you get to decide who gets access to it.
With the IndieWeb version of POSSE, the source of truth is the webpage you control.
For the ATProto version of POSSE, the source of truth is the record in your PDS. That record is interesting because it is both content-addressed and signed with your private key.
Where ever that record is syndicated, the reader (or app displaying the content) should be able to demonstrably verify the authenticity of the record.
And you can host your own PDS entirely independent of Bluesky, there are several interfaces for both reading and publishing Standard.site records:
* Leaflet (https://leaflet.pub/ )
* pckt (https://pckt.blog/ )
* Wordpress (https://github.com/pfefferle/wordpress-atproto )
It's also not that hard to write your own display interface for just your data if you want.
reply