i've been studying bluesky a lot and i'm interested in others opinions on "why, or why Not bluesky"
-
@luna technical 2 electric boogaloo: ps there's no such thing as privacy or limited visibility, everything is fully public by design and they didn't consider any access control layer
-
- 300 character limit is hardcoded at the schema level, you have to fork the entire network to change this (because it's centralized on app.bsky as a namespace)
yeah, i'd classify it as a fault... sort of... do you think a larger amount of projects/appviews being on top of atproto that make actual dedicated UIs instead of bodging everything together into the monolithic instance software you use make this less of an issue? (for example, https://whtwnd.com/)
- all the security features only work if you assume everyone is using the official bsky.app client
which features? you mean blocking?
- extensibility has already run into real-world issues with people stuffing data into other people's namespaces without permission
i'm assuming you mean this, which is definitely a fault in regards to them not validating lexicons as you'd expect. we (ap fedi) kind of still have the same problem but instead of stepping on each other's toes, it's that nobody is allowed to step on each other's toes, see the isCat extension that you can't expose in any way if you're not using misskey since your ap identity is very tied to the software you're running (though that's more Mastodon Protocol than AP, relates to nomadic identities, etc).
- the culture seems to be just as combative as twitter in some places
from tef's thread i would continue to say that this is an issue that is easily replicated on fedi, i myself have to be extremely controlling on who i follow to prevent that type of user/culture spread over to me, and bluesky would be able to do the same except via algorithmic feeds that keep subcommunities as subcommunities that don't interact with each other (hard problem, tbf)
economical: they have investors and they have debt. they need to make money somehow. good luck to them but we all know how this often turns out
yeah, the true test of all of their work will be when bluesky pbc explodes due to no funding and the remaining PDSes figure out how to spin themselves back up, or someone else spins up the BGS services and get a real foothold on the network that is as strong as bsky pbc
technical 2 electric boogaloo: ps there's no such thing as privacy or limited visibility, everything is fully public by design and they didn't consider any access control layer
well, they did say that on the signup form (though NOBODY will read that blocks are public i'm sure, and all the funny ramifications of that e.g a dedicated blockbot that you can use the data from to harass them later), but we both know how bad The Mastodon Protocol's security model goes (...out the window)
in 2024 roadmap they said they want to implement something for limited visibility:
Limited-Audience (Non-Public) Content: to start, we have prioritized the large-scale public conversation use cases in our protocol design, centered around the public data repository concept. While we support using the right tool for the job, and atproto is not trying to encompass every possible social modality, there are many situations and use-cases where having limited-audience content in the same overall application would be helpful. We intend to build a mechanism for group-private content sharing. It will likely be distinct from public data repositories and the Relay/firehose mechanism, but retain other parts of the protocol stack.
but there are a lot of statements and not enough real work to back them up. i'm trying to give them a more charitable interpretation given that they did do some real work that would be aligned with a vision that i would agree with (PDS, nomadic identity so you can move between PDSes, intentionally low-cost to run a PDS compared to AP instances since they hold everything, etc)
-
@luna i dont think appviews solve the problem that your posts and profile have to exist in the app.bsky.* repo. you can make records in other repos but people won't know to check them, and bsky users won't be able to see them so what's the point. it'd be like if all fedi objects had to exist under a hardcoded path like /org.joinmastodon/ or something. there's a LOT of hardcoding of names and terms like this throughout their tech stack. it has no good reason to be there.
-
@luna fun fact i found out literally today, your did service entry not only needs to be exactly of type `AtprotoPersonalDataServer`, it also needs to have an exact id of `#atproto_pds` and your signing key / verificationMethod needs an exact id of `#atproto`. this is separate from the `#atproto_labeler` + `AtprotoLabeler` which needs a *separate* key with exact id of `#atproto_label`, even if it's the same key / key material as the `#atproto` key
Labels - AT Protocol
Self-authenticating string annotations on accounts or content for moderation and other purposes.
AT Protocol (atproto.com)
Labels - AT Protocol
Self-authenticating string annotations on accounts or content for moderation and other purposes.
AT Protocol (atproto.com)
-
@luna this is of course on top of all their http api endpoints being hardcoded to /xrpc/ which was funny when someone registered an aws bucket with the name "xrpc"
-
@luna admittedly a lot of these technical details don't matter as much as the big-picture "you're stuck with 300 characters forever because someone thought that was a good idea once", but it does kinda tell you something about the dev culture there
-
@luna the security features yes i meant stuff like blocking and rescinding quote posts all relies entirely on "surely the client will know to check these records and respect their contents"
it works if almost everyone uses bsky.app but if alternative clients take off then there *will* be clients that let you bypass blocks, reply to or quote from people who block you, etc
this kinda stuff should be made abundantly clear to users imo, they need to know their security is like pic related:
-
@luna re: extensibility the problem is specifically that atproto with their schemas and lexicons will restrict what you can put *on each individual record*. so you end up needing sidecars. whereas in ap/fedi/jsonld you can put whatever statements/properties all on the same object and it's okay. you don't need sidecars. you do need to be careful to avoid conflicts but you can "easily" do that with namespacing or jsonld context
-
@luna i think the story is worse for plain json or ld-unaware impls (most of them lol) because if you expect very specific shorthand terms and those terms aren't there, you end up not knowing what to do at all. but it's still mostly okay because you can generally ignore whatever you don't understand
-
@luna re: the evolution of atproto i think i'm basically uninterested in it although i am still somewhat interested. not in bsky though, the bsky stuff is irredeemable to me as long as it's all-public and 300ch only. literally unusable
the funny thing is that atproto doesn't actually bring too much that's radically unique or new to the table, so you can build mostly the same thing on top of web architecture instead. which isn't much better but at least it's not a reinvention
-
infinite love ⴳreplied to infinite love ⴳ last edited by [email protected]
@luna one of the things from my mental model is that there are some common layers to communication protocols
- storage
- transport
- identitythen you have the finer details like data model and schema and semantics and whatever
atproto has a good story for storage and identity... but you could build the same with solid and dids (or even controller documents over https which are basically did documents without the did bits)
