grjte

0xPARC Supporting application R&D on Ethereum and decentralized platforms.

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

Homomorphically Encrypting CRDTs | jakelazaroff.com Homomorphic encryption allows a computer to run programs on encrypted data. Learn how homomorphic encryption works through interactive examples, build a homomorphically encrypted CRDT and see whether ...

📝 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!

Beta Waitlist — Germ Network Select \u201CAccept all\u201D to agree to our use of cookies and similar technologies to enhance your browsing experience, security, analytics and customization. Select \u201DManage cookies\u201D to…

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. 🧵

Exploring interoperability & composability for local-first software | grjte Check out the project at https://github.com/grjte/groundmist-syncCross-posted to https://baincapitalcrypto.com/atproto-for-local-first-interoperability/ This is the third exploration connecting local...

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

Exploring the AT Protocol as a legibility layer for local-first software | grjte Check out the project at https://notebook.groundmist.xyzCross-posted to https://baincapitalcrypto.com/atproto-for-local-first-legibility/ Some people like vim and some people like emacs and some peop...

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...

A more complex diagram of an interoperable system with multiple local-first apps that use the same lexicons and multiple atproto AppViews interoperating over the same public data and lexicons

8/ Second: local-first software applications can provide multiple AppViews for private data that _never gets published._ By using shared lexicons and data, independent local-first applications can smoothly interoperate, easily understand data sets, and modify them correctly.

A diagram of a simple interoperable system with a local-first app that can uses the same lexicon as an atproto AppView and can publish documents to the user's data repo for public display by the atproto AppView

7/ atproto lexicons + local-first software enables AppViews over local-first data, enabling 2 useful models.

First: local-first software can provide AppViews of private data and be connected via a lexicon to public AppViews that display data that was published to the AT Protocol

A view of the local-first Groundmist Editor application for drafting and editing markdown documents before publishing them to atproto

6/ To explore the idea of local-first AppViews connected to public lexicons, I made a local-first markdown editor for the @whtwnd.com blog using Automerge + @inkandswitch.com's "tiny essay editor". You can use it to draft your writing in private before publishing to atproto.

5/ How can we enable interoperability for local-first software? We can use Lexicon as a global schema network _without publishing data to the protocol_. Our software will still be local-first, but we'll leverage atproto's structured legibility layer to manage interoperable data.

4/ Local-first software champions user ownership and control.

✅ Local & private by default
✅ Works seamlessly offline
✅ Instant interactions—no loading spinners

But each app lives in its own universe - there's no connectivity layer for easily reusing or composing data.

3/ atproto enables interface flexibility through its global schema network called Lexicon. Lexicon is used so every AppView on the network can agree on semantics and behaviour. It defines a schema definition language, as well as specifying the data's collection.

Two different side-by-side views of the same Groundmist Library data from my atproto data repo

2/ First, check out the flexibility of AppViews on the AT Protocol. Here are 2 different views of the data from my Groundmist Library collection, one on the Groundmist Library site and the other on my website. They both use the same underlying data from my atproto data repo.

1/ Seph Gentle on @localfirst.fm put it like this: "_Some people like vim and some people like emacs and some people like something else, and why not have our documents able to be edited in all of those programs?_" Beyond code - why not for data across all disciplines?