In a short paragraph, tell us about your project and what you're building.

Weaver is designed to be a highly flexible platform for medium and long-form writing on atproto. I was inspired by how weaver birds build their own homes, and by the notebooks, physical and virtual, that I create in the course of my work, to ideate, to document, and to inform. The initial proof-of-concept is a static site generator, able to turn a Markdown text file or a folder of Markdown files, such as an Obsidian vault or git repository documentation, into a static "notebook" site. The file is uploaded to your PDS, where it can be accessed, either directly, via a minimal appview layer that provides a friendlier web address than an XRPC request or CDN link, or hosted on a platform of your choice, be that your own server or any other static site hosting service. The intermediate goal is an elegant and intuitive writing platform with collaborative editing and straightforward, immediate publishing via a web-app. The ultimate goal is to build a platform suitable for professional writers and journalists, an open alternative to platforms like Substack, with ways for readers to support writers, all on the AT protocol. Currently it is in the earliest stages of development, working on core components such as the parsing and rendering backend, command-line client, and initial appview. The plan is to have the proof-of-concept ready for testing in June, and to immediately begin using it for my own writing, as well as information and updates about the project.

How do you plan to use this grant? Feel free to be specific.

I plan to use the grant money to help with hosting and/or hardware costs (such as VPS rental fees or upgrades to my homelab, like a backup internet connection), and potentially to offset the costs of incorporation. If I'm not able to dedicate enough time to this or bring other people onto the project, it won't get off the ground, and some help with expenses makes that possible.

Who are you? Please provide a brief bio or background about yourself.

I'm Orual, an electronics designer and software engineer who routinely works across the entire stack from bare metal microcontrollers all the way up to web services, UX development, and AI. I grew up getting mail delivered by single-engine Cessna airplane to a grass airstrip outside a tiny village in Congo and listening to my parents talk with people half-way across the country on a short-wave radio, later using an early satellite phone to send email, the ultimate decentralized information network, maybe. I wrote my first line of code when I was ten, started building robots soon after, got into university for engineering, designed and built electronic musical instruments, dropped out of university, transitioned my sex, learned a ton about programming and electronics, went back to college and got into research.

Currently, I work part-time as a principal investigator in a small applied research lab at a college, helping startups and other businesses with product development and prototyping. I'm a long-time enthusiast for blogging and other forms of extended online writing, but have always been dissatisfied with existing solutions, which is the impetus for Weaver, and because of my experience across the whole tech stack, I think I can deliver something really great.

What excites you about building in the ATProto/Bluesky ecosystem? This helps us understand what's driving you.

I'm a Utopian in the Terra Ignota sense. I want to see us flourish and go out into the universe. I want people to be free and able to create and build wonders, not beholden to any sovereigns, in whatever forms they wish. My vocation is engineering. It is the thing I cannot help but do, and I take great pleasure and pride in it. In the ATProto ecosystem I see a way to direct my skills toward creating the kinds of tools and platforms that empower people.

I got onto Bluesky early and was immediately hooked for a number of reasons. The first is the actual protocol itself. How it does identity, how the user maintains control over their identity and data, largely independent of hosting and services, and how no single service needs to do it all, you can mix and match. It's the embodiment of a lot of the ideas I've had about how the social web should work for a long time.

In addition to championing the atproto identity model and overall philosophy to clients at work, I’ve done some early explorations with private data and varied interaction modalities via embedded systems, such as a Rust XRPC client for microcontrollers like the ESP32. I've been watching projects like Whitewind and Leaflet explore the long-form atproto writing space, and I think there's room for a more flexible, extensible, and collaborative approach to the concept on the protocol.

The other primary staying factor has been the community. The Bluesky dev team has been so enthusiastic and welcoming for those who want to work on and with the protocol. One personal example is that of Morpho, an Android Bluesky client, which received an ATProtocol microgrant. I’ve made a lot of friends on Bluesky, and I want to grow the ecosystem which allowed that to happen, to help it flourish and become more than just a grand dream behind a Twitter clone.

How does your project align with our goal of accelerating growth in the ATProto/Bluesky ecosystem with developer tools?

The initial alpha version of Weaver is targeted at developers and people otherwise comfortable with a terminal. It aims to bring the process of documenting your tools, educating people, and otherwise writing and publishing things that don’t fit well into a Bluesky post or thread onto the protocol in a way that is highly flexible. If that is all that it does, that’s excellent and meets a need that I see in the community. It would provide a consistent way to make a blog built on ATProto without everyone having to reinvent part or all of the wheel, or do programming they don't want to do.

As Weaver develops further and targets a less technical audience, it will retain those more developer-focused modes of use, for people who want to do something more specialized with it, have a workflow they like which doesn’t mesh with the web editor (and if they want to write their own tooling on top of Weaver, more power to them), or just want to run it all themselves. Developers are also the initial audience because the alpha will inevitably be rough around the edges, and nobody provides quality feedback like other developers.

How does your project align with our goal of empowering communities with the tools to cultivate and sustain themselves?

Communities don’t just need microblogging posts and algorithmic feeds. They need places for longer-form content, less ephemeral works they can point to; stories, essays, rules, histories, articles, and so on. One of the biggest downsides of so many companies and communities moving onto closed platforms like Discord was the lack of durability of any content by default and the inability to easily access and search it from outside the platform, and one of the downsides of “identity-follower”-based platforms like Bluesky (where relationships are about following specific people) is that they produce communities highly focused on specific people as much as specific topics or interests. Weaver notebooks and entries within them can be throwaways, but they’re intended to stick around and remain accessible in a consistent way (unless taken down).

There’s a need for better tools for that kind of thing on the protocol right now, as currently a lot of stuff is bespoke, feels incomplete as an experience, or is just not really connected to the protocol and so misses on some of the data ownership of ATProto.

One aspect which makes Weaver as designed good for communities is simply that, unlike with Bluesky, where a follower is a follower and you only have one identity, you can have more than one notebook (and they can be shared between multiple authors), and more than one author profile. Someone might make a personal blog, or one for a project, or to write a piece of web fiction with a friend, either all under the same profile or under different ones, as fits their wants and needs. People have different contextual identities but don’t necessarily want to make alt accounts, and a writing platform for people should reflect that.

Collaborative editing is a great feature for communities as well. People can workshop something with their friends and then publish it instantly. You could build a wiki for a fandom community on Weaver. Two journalists could publish a newsletter together, and bring on an editor to tighten up their articles. And over time, Weaver would ultimately support payments, helping creators fund their work.

How does your project align with our goal of giving people direct, unmediated access to their audiences?

The first and maybe most powerful thing I’m going to give people that sort of direct and durable access is building complete self-hosting into it from day 1, inverting the pattern Bluesky followed. Weaver is designed to outlive Bluesky and even to some extent the AT Protocol. The failure mode is much the same as a tool like Obsidian, which is a direct inspiration. Because the core document format is Markdown, which is fundamentally just a text file you can load up in any editor, and the basic tools are designed to work without any ATProto authentication, people can keep using them and easily port or host the contents however they wish. You can go where your audience is.

Beyond that, the platform features are all about making the process of writing something and putting it out there for people to read as simple as possible, in a way that means you have ownership of that data, the same as anything else on the protocol, Even when collaborating on a document, you retain control, via much the same means that each person's repository uses to maintain consistency. And since it's designed to interoperate widely, you can easily bring notebooks and entries from Weaver to your audience on Bluesky or any other ATProto platform, and they can comment on them from Bluesky.

Other things to share?

Here's a bit more technical detail on what will underpin the collaborative features. A notebook entry on the protocol is a type of CRDT, a conflict-free replicated data type, built on top of Loro, stored as a series of your edit records on top of a root record in your own repository (with others’ edit records being stored in their own repositories), along with the contents of the most recently seen (and most recently published) versions.

With the combination of those pieces, if one person deletes a notebook or entry, everyone else in the list of authors retains the contents and can recreate most of the edit history, even if the Weaver appview doesn't have the deleted records cached.

The appview itself is a couple of components. One is a lightweight entryway service, which mostly provides that friendly external url for published notebooks, redirecting to an author's PDS or a CDN and handling some authentication (e.g. to ensure that, while an unpublished or controlled-audience notebook or entry does exist in one's PDS unencrypted, one cannot just navigate to it). The second component is the backend for the collaborative features and will host the web-based editing and navigation interface. All of this is designed to be used or run independently if desired.