Although I like the idea of decentralization, the atProtocol is relatively new and still evolving. This means less documentation, fewer examples, potential API changes, and limited community support compared to established stacks.

Also as a solo founder, implementing a decentralized architecture adds significant complexity compared to traditional client-server models, which I would need to learn new patterns and deal with distributed systems challenges for.

With ATProto, you don't have to implement most of the federation. For your project specifically, it would be called an "AppView" in atproto lingo. You would...

1. store public data in the user's PDS (an api call instead of a db call)

2. listen to the firehose for records created by other frontends to your AppView (optional, especially early on)

Otherwise, it would be quite similar to any other social media site with mobile apps, a backend, and a database

Decentralization is definitely on my long-term roadmap for Airdel, and AT Protocol has some interesting benefits worth exploring. However, my immediate focus is on market validation and getting a viable product into users' hands quickly. As a solo founder, I need to be strategic with my resources.

Right now I'm prioritizing core functionality and user experience to test if we're solving the right problems. Once I've validated the concept and built a development team, implementing decentralized features would make more sense as we scale.

I appreciate the suggestion though - it's on my radar for future iterations when we have the bandwidth to implement it properly!