@trwnh
- 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)
