You write to canonical storage and then do an optimistic write to the index so the app can see it right away. Eventually the update will come through the indexer (view) which “upserts” into the index.

By now everyone should have patched their Nextjs/React apps to fix the React2Shell CVE. In addition to that consider using a WAF with a rule that blocks known bad inputs.
#atdev

and they complain on their smartphone. That was manufactured in an optimized factory floor. Routed to them across the planet on an efficient route. After paying for it on a system that determined the transaction was not fraudulent. They are screaming children who don't know how anything works.

This looks great! In addition to the neighborhood scope are there plans to support condo/apt building groups? These are huge on Facebook and one of the things that keep people on that platform. Hopefully login with atproto is also in the plans?

I suspect people often block accounts in situations where a mute would've been better. As in "I keep seeing this account on all my feeds and it feels like it sucks up all the oxygen in the room". Maybe the block feels like they're punishing the account and it makes them feel better? 🤷🏻
#atproto

haven't looked into any of them but I wonder how many are mostly redundant and how many are more like sidecar records with strictly complementary information. In the latter case I'd name them differently, but maybe that's just me.

Sounds like you might have experience with companies that offer an abstraction layer on top of this. I'm not familiar with those but wouldn't be surprised if they charge a hefty premium for it. Depending on your goals it might be worth diving into the underlying tech so you can skip those layers.

my reply was to a different post discussing general advice, not the OP.

A common and cheap setup is to host a static website on object storage and serve it through a CDN. This static site would then call the serverless functions through an API gateway.

Hosting server-side code comes down to 3 options: virtual machines, containers, or serverless functions. Serverless tends to be really cheap with vendors where you pay only for runtime and memory; particularly those with a generous free tier.

That seems unavoidable. Without access to the apps, all the activity you can see is whatever generates events that flow through the relays so it sounds like you're already doing what can reasonably be expected.

The repo record itself doesn’t have versioning so you would only see the latest version or in the case of a deleted record nothing at all, iirc.
The relay that puts out the firehose has a retention period of a couple of days, so you could replay recent events but not from the beginning of time.

there's no need to subpoena anything. The government (or anyone else) can subscribe to the event log service aka firehose and get all the events in the network for archival. You should assume they already do.

Familiarity for Substack users seems to me like higher priority than anything else. I wouldn't waste time on a whole new design at the beginning: the time where you have the least amount of information you'll ever have. There's a reason bsky looks just like Twitter.

The public has better things to do than learning about decentralized protocols just to use an app. Nobody's demanding you learn about battery chemistry and kinetic energy before selling you a car.
It's OK to use language all your users will understand.
#atproto

The short answer is that Bluesky is not in charge of your following list. You are.
You're the only one who can edit the list of accounts you follow and nobody else has permissions to edit it for you; not Bluesky, not the people you follow, only you.

We already have a few bookmark services on atproto but if you're going to build one please use the community lexicon for it so it will be compatible with other good citizens of the ecosystem: community.lexicon.bookmarks.bookmark

Don't feel bad for not having your main account on a self-hosted PDS. For almost everyone it's pointless other than it being a learning exercise.
You're better off setting up rotation keys/backups in case you ever need to migrate (you probably won't).

What's cardy? Can't find anything about it online.

exactly. The longer we go without private records, the more tempted apps will be to stop seeing the PDS as canonical storage.

There are too many people who can write code but haven't learned to think like an engineer and the overconfidence it creates is detrimental to them and everyone around them.

At first I thought you were being sarcastic, describing how Bluesky's underlying protocol works, more or less. But it's pretty insightful that you saw it this way without knowing that. Nice!

Personal Data Server, the component that stores your account and content like your posts and images. A separate component is the apps that interact with it like Bluesky and many others.

If the client is going to the app for the optimistic update why not go to the app for the original mutation too? Seems cleaner.

Good to hear! Good luck with the rest of the process recovering your account

Careful, using a script to follow people from an old account can get your account suspended. Ask me how I know.

OAuth scopes are coming soon. In the meantime it's just like any OS app that is not sandboxed: The reputational damage an app would suffer for doing something malicious like that is enough to stop it.

With potentially some exceptions like maybe an app needs to keep an internal record that you agreed to the Terms for legal reasons but deleting everything else.

You would still be "visible" in the sense that you can see Obama's profile on Tangled because it's a Bluesky profile record but that's just a matter of educating the user on what it means.

A reasonable standard would be: there's no difference between a "deactivated" app and an app you've never used. So deactivation would be deleting the collection(s) from your PDS and all your indexed data on that App, including private/internal data.