I think these are pretty good predictions, or at least line up with the goals we’re pursuing. I believe private data will land in atproto, hopefully by mid year. I also expect the tooling will improve a lot; the new Tap tool has made backfill and sync a lot easier, and the moderation tools are also going to improve a lot (the Osprey automod tool built with ROOST is great). That’s all pretty key for building applications.
Also quick prediction the Atmosphere conference in March should be a good time
Funny timing, we just published an RFC on a contact-matching scheme that's intended to be resilient to this kind of enumeration attack at the cost of reduced discovery. We're soliciting feedback so now's a good time to share the link - https://docs.bsky.app/blog/contact-import-rfc
Related to Zero Knowledge Proofs, the advantage is that phone numbers need never be shared in cleartext, preempting whole classes of attacks. However, could be overkill for your needs, and I am not sure how well current techniques would scale.
The RFC addresses security, but does not mention anything about privacy.
I think the scheme ultimately boils down to trusting the server/instance.
It would be great if users don't have to share the actual number with the server,
a hash or something like that but that would make it impossible to verify the number and verification is required to prevent spoofing.
Another way maybe is to have a trusted 3rd party (something like EFF, LetsEncrypt) that can be used by users to validate their numbers and applications can get the hashes from there.
Ah its great you bring this up, it's timely as my app is adding contacts syncing soon and I want to do it in a secure/private way. If you choose to go ahead with this, are there any plans to make it open source? ty!
Ok, let’s not have the is Bluesky decentralised discussion again. Kudos to Bluesky’s PR efforts to use complex technology to basically sell themselves as whatever people want to hear (like NFTs but social media). There are a number of X/Threads clones out there, but I’d take a group chat on some relatively secure messaging platform over “social media” any day. Even better if it’s something I can self host or join into one from many servers (remember IRC? Good times).
We really need to rethink this “one corp owns all the keys and all servers” setup.
That's opt-in, mangles usernames, and on top of that quite a few people on Mastodon seemed allergic to the very idea of bridging/federation the last time I looked into it.
So? It's just an example. I'm sure you could do it in a cleaner way. They use different protocols. If you can run your own server and connect with open source tools, it's decentralized. Though of course that doesn't mean a decentralized protocol isn't highly centralized. See email
Put me in the camp of “animation is valuable even when it’s redundant information.” Guiding the eye and helping to digest information is valuable, and even the slop examples are useful in my opinion
I kind of feel like you’re taking one of the specs from nostr - the first one written - and calling that the whole protocol. Then you’re comparing all of the atproto specs to that one spec.
The substantive difference is that we didn’t do a mix & match spec process because we knew the ambiguity of spec support causes problems, just as it did with XMPP. Protocol specs only get implemented a few times. The meaningful developer choices are in schemas and business logic.
But that's essentially the whole protocol. You can implement a client or a server reading only NIP-01 and it will be able to interoperate with the rest of Nostr.
Reading and implementing NIP-01 can be done in an afternoon (or a weekend if you're taking your time), and it gets you relays that can accommodate multiple clients and applications. From the client perspective, only implementing NIP-01 gets you a simple Twitter clone with an identity that belongs to you.
the spirit of my comment was more psychological than technical. nip-1 successfully nerd-sniped my brain into thinking it was easy to get started with a simple, barely functional client. (even though, you're right, at scale, everything gets complicated and is not easy.)
perhaps this a roundabout way of hoping there is already a developer-focused quick start or tutorial for making a barely functional AT client. it either already exists, but i didn't look hard enough for it, or it might only be one chatgpt or claude prompt away.
Applications on atproto run moderation as a kind of filtering layer on top of the user data. A ban in that scenario is fully filtering their account out of the application.
I think there’s a lot of misconceptions about atproto; unlike ActivityPub where your home server runs both the application as well as stores your data, atproto is build in the concept that “applications” like BlueSky store your data inside your PDS (Personal Data Store), which may or may not be hosted somewhere else.
While anybody can host their own PDS, the public bsky.app instance can and will “block” users by preventing their login and not pulling data from the PDS of the banned user or showing it in feeds.
Since, to date, the BlueSky “AppView” (the service backend itself that handles aggregating data, generating feeds, etc.) continues to be closed, being banned from the public instance is effectively being banned from the network. The data model (lexicon) is well documented and somebody else is free to write their own, but, for now, BlueSky is just as centralized as other platforms even if you can store your data elsewhere.
What are you talking about? Yes, it is closed - their PDS implementation and clients are open, but the actual service that runs on bsky.app is, at present, not open source.
Without the backend that handles all of the XRPC endpoints [1] being available, BlueSky still effectively maintains centralized control over their part of the 'atmosphere'. Somebody could, of course, make an open source implementation of the app.bsky lexicon and users would only need to update their DID to point at their preferred instance, but AFAIK none exists right now.
Would projects like this one, which pulls only a subset of Bluesky data straight from the firehose, and can be processed as the end user pleases, help mitigate this limitation?
Bluesky is still the arbiter of what their firehouse emits
Theoretically they could maintain that filtering only occurs on the client level but they've made the choice to exclude banned users from the firehouse so their moderation choices effect everyone
Bluesky is building an open internet protocol (https://atproto.com) and a flagship social app (https://bsky.app). We're a company of 30 with a strong focus on fostering a high-agency, talented team. The golang roles are focused on building the internal platform with a whole lot distributed systems engineering; the ML is working on our many recommender systems and feeds; the RN & fullstack engineers are working on the social app and internal moderation tooling, respectively.
reply