@stupidplusplus if it's not too much trouble, i might be able to get that working too- appreciate it! worst-case scenario, there's always wine/proton. thanks for getting back despite this being a much older project! (i had no idea ;p)
@freeplay bluesky's content warning system is kinda crappy compared to fedi, fwiw. it's not very well-communicated (compared to most fedi apps i've used), and they don't allow anywhere near the granularity of fedi content warnings :/
@zuiderzeemeermin i do think further migration to fedi is possible! just that for the reasons above it will remain a slow, difficult, and likely incomplete process.
in any case, i welcome both activitypub and atproto to exist in harmony, playing to their strengths, and helping to build a communication network free of corporate and government overreach <3
@zuiderzeemeermin re: "why not just have them migrate here?", for the same reasons we couldn't get twitter users to migrate here. it's a mixture of cultural and technical limitations. from the woes of federation bugs, to the lack of discoverability (fwiw i adore the chronological following feed, but this is particularly devastating to most artists), to the simple chicken-and-egg problem of "my friends aren't here already, so i won't bother".
bluesky was also particularly welcoming to the immigrating twitter crowd (the user interface is very familiar, engaging with the platform was almost identical to twitter, etc.). the fediverse (in my view) has instead been actively hostile to most twitter refugees. many cool instances i federate with have mastodon(dot)social (who we understand to be the "flagship" instance) blocked or limited in some way. the environment, for those on the outside, appears very cliquey, and that's really intimidating when you're potentially moving your entire online identity somewhere. that's not to mention the regular occurrence of "fedi meta/drama", which i've been told by outside sources has been a particularly sore spot.
@zuiderzeemeermin first, i did not imply both are necessarily "equally bad". i very clearly stated that they both have pros and cons, and both struggle for various reasons; many of which were too nuanced and detailed to include in my original post. i think both are particularly good takes on a decentralised social media protocol, but both succeed more in certain areas than the other.
it's important to note that atproto is a much newer, far less mature protocol. third-party PDS (personal data server) software is still very much in its infancy (arguably, so is the first-party one; we still lack TOTP beyond email codes, and self-hosted PDSes don't even get that), self-hostable appviews (the service that provides the curated app feed for users) are still a big problem with only a theoretical solution. the ecosystem is quite flawed right now, but that's primarily down to a lack of maturity. this is something that will inevitably improve with time, much like activitypub.
as for how we can specifically improve atproto's decentralisation, this is something that has been discussed at length in the sphere. here are some proposals (some of which are already underway):
- extensive work building bespoke PDS software, without any involvement from the bluesky team. because of how atproto is designed, a compliant PDS should be compatible with core bluesky functionality without any bluesky-specific code; it mostly just responds to record retrieval/creation requests (bluesky has unfortunately built a lot of proprietary endpoints since launch, but this functionality can still be reimplemented by third parties)
- encouraging people to migrate to, and host third-party community PDSes. like the activitypub ecosystem, a community host can house many users' data, but unlike activitypub, this data is fully-portable, and can bounce between PDSes at any time. there are even resiliency considerations built into atproto which enable users to migrate from a rogue instance.
- expediting work on a self-hostable, scoped appview. currently, bluesky's appview requires an incredible amount of resources to run: appviews act as a constellation mirror of all PDSes that it scrapes; this requires potentially terabytes of storage, and an immense amount of processing, memory, and network capacity. a scoped appview would (ideally) only collect and save the social graph (plus some extras) of users utilising the appview, greatly reducing resource requirements. such implementations do already exist, but they're rough around the edges, and system requirements are still quite high.
if these three criteria were met (particularly the self-hosted appview), then atproto as a network would quickly become resilient to enshittification and censorship on the same level as the fediverse.
fun fact: i have not spent a single cent of the revenue from bandcamp releases since free2play yet. i'm hoping to save it up to reinvest into a really cool future project :3
@privateger very cool, thanks! actually used ATP airport to help migrate @zaire to a PDS i host. didn't realise it could also get rotation keys for you (though i suppose that would be pretty easy to add on top of their existing offerings)
@5225225 re: public registry, there is a very unofficial PDS scraper hosted on github by @mary_ext: github.com/mary-ext/atproto-scraping note that not a lot of these PDSes are open, and not all of them are up-to-date.
@5225225 definitely, if bluesky disappeared tomorrow, the atproto network would mostly disappear. there would be a couple dozen users running their own appviews who would still have full network access, but only able to fully interact with those also on non-bluesky PDSes and appviews. users who do not already have their DIDs migrated will likely lose their identity unless they had their private key saved somewhere (who does this?)
@ity i used to have my server lock up after any post that blew up a little too much. i've since moved my instance to a new VPS with more resources available and it's much more stable, but that really only confirms my point.
@ity to be clear, neither hosting an atproto PDS or activitypub instance are particularly easy; the process of even obtaining a server to run on is already beyond what most users could understand without a great deal of training (most of my circles are very technical nerds, at least compared to most people out in the real world)
my argument was simple that an activitypub instance is comparatively harder to spin up than an atproto PDS, which ultimately demands far less from you once set up.
@ity the system requirements are more demanding; the act of federation can often bring a server to its knees in the early days of an instance (at least this has certainly happened to me for both instances i've run); atproto's PDS setup, while expecting all hosts to run a very specific system configuration, does provide a very quick setup process for those who are less experienced with hosting.
@ari@arimelody.space