7/ Check out the details, including a deeper discussion of challenges, a prototype of Bitchat over Wi-Fi Aware, and general notes on cross-platform Wi-Fi Aware implementation
👉 grjte.sh/bitchat-wifi...
6/ Wi-Fi Aware would complement BLE as a secondary transport to boost connectivity or enable high-throughput direct messaging. BLE provides a backbone for a ubiquitous baseline mesh. Wi-Fi Aware enables extended range and higher-bandwidth hops when devices both support it.
5/ Wi-Fi Aware has challenges: cross-platform support isn’t uniform; pairing flows and asymmetric connection limits complicate mesh formation; hardware support varies. But they're not insurmountable, and Wi-Fi Aware could be used today to improve Bitchat and similar networks.
4/ Surprisingly, the power cost during discovery was similar between BLE and Wi-Fi Aware, thanks to the optimizations of the Neighbor Awareness Networking (NAN) protocol underlying Wi-Fi Aware. Active transfers consume more energy, but support significantly higher data rates.
3/ Wi-Fi Aware throughput is orders of magnitude higher than BLE. In practice, Wi-Fi Aware's range on mobile devices can also be significantly higher than BLE. In tests, we saw ~4-5× improvement. Increased range means fewer devices are needed to form a reliably connected network.
2/ Wi-Fi Aware is a wireless discovery and mobile p2p networking standard long-supported on Android (2017) and newly supported on iOS (2025). It lets devices efficiently find each other and set up high-bandwidth Wi-Fi links without an access point.
1/ Bitchat today uses a BLE mesh for ad-hoc messaging without internet access. BLE is ubiquitous and low-power, but its short range (≈10–30 m) and low throughput can limit the real-world reliability and coverage of offline mobile ad-hoc networks that depend on it.
🧵 Could Bitchat have 5x the range and 100x the throughput for the same power expenditure? I explored how Wi-Fi Aware could improve the reliability and throughput of Bitchat and mobile ad-hoc networks in the absence of internet connectivity. #bitchat
👇
2/ Particular thanks to @expede.wtf @patternist.xyz for helpful discussions beforehand and @inkandswitch.com @martin.kleppmann.com @jakelazaroff.com @jessmart.in for referenced work
For an intro to the idea of "programmable cryptography" see gubsheep's excellent essay: 0xparc.org/blog/program...
1/ Had a great time on the ZK podcast chatting about local-first and emerging use cases for programmable cryptography (ZK, HE, MPC) with @goblinoats.com @arro.bsky.social @nicomnbl.bsky.social . I'm excited for more exploration here & I'd love to hear ideas from both local-first & prog crypto worlds
👋I was just talking about your local-first conference talk on a podcast yesterday. I love your new website design too! Fun to engage with & exactly the kind of unique personalized view over PDS data that I was envisioning
📝 new blog post! i spent a while looking into homomorphically encrypted CRDTs. spoiler alert: they don’t work super well!
(but you should still check it out — i break down what homomorphic encryption is and how it works, and there are lots of explorable explanations along the way!)
screenshot of our "Leaflet Lab Notes" publication homepage, with one post listed, at https://lab.leaflet.pub/
screenshot of a record from @leaflet.pub's PDS, showing the data for the Leaflet Lab Notes publication, at https://pdsls.dev/at://did:plc:btxrwcaeyodrap5mnjw2fvmz/pub.leaflet.publication
Leaflet Publications: blogging on Bluesky — version 0.1 is here!
✅ now: make publications, add posts, publish to Bluesky
🗓️ soon: subscribing, commenting & other social features
Try it: leaflet.pub/home
We'd love your feedback & ideas for how we can make this great!
We built the DMs we wish existed: a messenger that lets you share what you want people to know, and nothing else.
But what if you wanted them to know…your ATProto handle? 🤯
I've been working on a network-local ATProtocol dev environment that gives me end-to-end production functionality for Smoke Signal, including handle resolution and repository access. Here’s how I put it together. 🧵
9/
A personal sync server acts as your local-first PDS, offering local-first benefits—like offline access, data ownership, and multi-device support—while enabling the interoperability and flexibility of the AT Protocol.
👉 Read more: whtwnd.com/grjte.sh/3ln...
8/
Because your apps are local-first, the user-centric data repo that your personal sync server provides is portable, just like your atproto identity. Update the location of your PSS, and your local-first data will sync in the new data store as you continue to use your apps.
7/
With this foundation, any AppView you want to use for interacting with your local-first data can sync and use multiple data types from your PSS without having access to the full PSS. You can do this from any device, even using different services for different devices.
6/
This personal sync server (PSS) model can enable local-first interoperability. atproto identity can be used as a user-centric identity for managing and connecting to the sync server. Data can be structured, stored, and permissioned according to a Lexicon definition.
5/
This can be fixed by following atproto's lead and making an architectural shift from app-centric sync servers to user-centric sync servers. Instead of local-first apps syncing data to the same server regardless of the user, each user's data syncs to a personal sync server.
4/
In the local-first context, data interoperability is challenging partly because it lacks atproto's data model separation. It also lacks user-centric identity, schema standardization, a permission system, and a discovery mechanism, all of which facilitate apps sharing data.
3/
For data interoperability across services, we need legibility as well as discoverability and accessibility beyond the original app. atproto enables this by combining the Lexicon system with data model separation where user-centric data repos are separated from AppViews.
2/
The latest Groundmist experiment explores how a personal sync server can function as a local-first data store, mirroring the role of an atproto Personal Data Server (PDS) and building on the lexicon schema system's foundation to enable interoperability over local-first data.
1/
In the 1st Groundmist experiment, we used atproto as a publishing target for data drafted privately in a local-first context. In the 2nd, we explored atproto's Lexicon schema system as a legibility foundation for describing how to interact with various local-first data.
🧵 The AT Protocol shows the power of a personal data store. All of our public atproto data is easy to find and access. We can interact with it flexibly in myriad ways and combinations.
Wouldn't it be nice to do the same for our private and collaborative data? 👇
Yeah this is an interesting point - currently the publishing is one way from private to public, but it would be great to be able to sync in both directions. There are a few issues to think through here that I mentioned in a related github issue someone raised: github.com/grjte/ground...
what's the purpose of the modes? the first part makes sense to me. what's the extra power you want from the server/client model?
Yes, I'd love to see this pattern applied to knowledge graph notes. Long form markdown was a simple place to start, but having a mixed local-first/public knowledge graph would be so useful. I'll catch up on your notes & would love to chat more also with @cdata.earth @mathewlowry.bsky.social
Interesting! My PSS prototype is built as a sync server for automerge documents, so the storage is managed by github.com/automerge/au.... I just define where to store those repos, and I do it according to a specified lexicon NSID, storing data along that path
9/ Combining atproto's Lexicon schema system with local-first software offers a lightweight way to unlock interoperability. If you're interested in these ideas or working on similar ones, I'd love to hear from you.
👉 Read the post: whtwnd.com/grjte.sh/3ln...
