Ourcana

"It's 10pm, do you know what your Plural System's data transport security is?"

Heni here once again! Today I'd like to follow up on my last post about Willow and give an update on how Ourcana's online (and local device sync!) features will function!

The mistakes of the past

Programmers familiar with online security models even as recent as 2015, if not as early as before 2002, may tell you that "Authentication" and "Encryption" were considered two different things. "Authentication" was making sure your user(s) were actually logging in, then you got them "Encryption" through something like https:// connections and that was that.

This model works, but can lead to a class of privacy bugs common in older software. Improper security design, as well as compromises made to "just get the software out there", can be devastating.

Sometimes, application developers just straight up skip a step! The PluralKit model is one such example. System and Member/proxy data is not encrypted in the live database itself. As explicitly stated by PluralKit's hardware owner, Iris, in public, she holds the keys to data via "Full Disk Encryption" (FDE) to satisfy Discord's requirement of "at-rest encryption" for all bot developers. However, the data is still readable while the server is powered on by anyone who compromises the app... or by Iris herself, and anyone she's delegated access to. "FDE" protects only a powered-off disk, and nothing is end-to-end... these are concrete security and privacy gaps. It’s unlikely they’ll see a fix as she’s said in public, in the context of many architectural nits, "that [these] aren’t really issues" — the exact words of the person able to open it all in the first place.

This is, ostensibly, the honor system of privacy models.

The entirety of the privacy model in PluralKit is thus predicated on the login system actually working correctly (and trust in developers with login access to production). If one can "log in" as another user, it's trivial to fetch their system data. And sometimes one can simply attack the system or server itself to access the data. Very few developers today authenticate between internal servers, which means if one is compromised due to a bug or exploit they're all exposed.

How many websites fall under fire today for similar mistakes? To give a fake example for a very real type of headline we see in 2026:

Poob's entire database of ten thousand users was found exposed on the public net today. Every user's photo ID, birth certificate, and social security number was left unencrypted in the database.

Developers, whether through inexperience or by offloading their mental work or responsibilities, are prone to incorporating security as the last step in their software design, if ever. And it's users that pay the price, not the service operators.

This is not to say the solutions are impossible. What if even if the database were compromised, encryption secured one's data? What if even the developers of an application couldn't read your data as a fact of the math not just the honor system?

There's a better way.

Authenticated Encryption with Associated Data

Or more tersely "AEAD" is the security and privacy model in vogue with programmers today.

For example, the TLS v1.3 standard, the peak of online security today and possibly what you're using to access this website right now says:

all ciphers are modeled as Authenticated Encryption with Associated Data (AEAD)

— RFC 8446

The nature of how exactly this is implemented is best left to academics and cryptography experts, but I can show some of the practical reasons to use such a model with charts I've sketched up in my time working with the worm blossom duo behind inventions such as the Willow Protocol of which Ourcana may be the first application to use in the real world in a serious way.

The particulars of what this looks like can be seen in the diagram below, and have already been released in the worm-blossom Discord forum for preview by academics and researchers before my actual release of Ourcana Online built out of it.

In this case, we're assembling data left to right, and the "thatch" section is where a mix of encrypted and authenticated but not encrypted data reaches the server, after the users' phone or device has finished doing the cryptographic math locally (all in just a few milliseconds, thankfully).

The Relay problem (and solution!)

A user could send a completely encrypted blob to a remote server or database to hold onto for them. Using techniques such as an "encoding" of Willow to an on-disk store and document index (literally, a database) it's possible for users to start asking for their records and sharing them with other peers. "Give me my front history again." or perhaps "tell me Heni's front history, here's a signed ticket from her proving I'm her friend and she said she wants to share it with me in the future".

But in the case where a server operator has 100% unlimited access to all data on the server, privacy isn't actually guaranteed. After all, can't they just look?

With encryption, users can exchange keys, do math, and functionally encrypt their data. But then if the data is encrypted, how would the server know where (as in who) to send the data to? "Here's a binary blob that's totally private" doesn't help the server out at all. The server can't, for example, send a push notification to another app, or pull a profile picture to re-host it for a Discord proxy if all the data is completely encrypted.

I've identified a few different types of "partial encryption schemes" that may actually be useful for Plural systems trying to reach their friends and loved ones, in the diagram below

Shown in the first diagram, but perhaps not immediately obvious, is the idea that we create an "envelope". The "outside" of the envelope is a signed proof that anyone can read. "This message is from Heni, to her friend Alice. Any push notification server is allowed to tell Alice that the message is from Heni. You are not allowed to open the envelope." Inside the envelope is an encrypted blob. Even if a server does break the rules and peek inside, it just appears to be random noise. There's nothing useful without a decryption key that only Alice has locally (if she keeps it secure and private, that is).

Trust no one, not even your server

My privacy model, while novel in application, is built of standard, off-the-shelf parts. Using bab I've spent the past week talking to Aljoscha and Sammy from worm-blossom doing my best to prove their theories on actual hardware, using production-tier application design.

Bab hashes allow for, through a Merkle tree system, the partial verification and total verification of data in transport. This means it's possible to definitively prove that Alice or Heni actually authored a message, provided you've registered their public keys for the math. There's zero trust in the server required to know you're speaking to your friends and not an imposter.

I ran a little benchmark on my 5-year-old Apple MacBook Pro M1 Max laptop (and a friend ran it on his similar tier AMD-based laptop) and I was very excited to see that even low-tier consumer hardware like a 10-year-old laptop should be fast enough to back up a user's own data from their phone.

Action on the Discord

As an aside, I& can be found on the Ourcana community Discord, which will soon support a Matrix.org compatible bridge to link both services for those who would rather not use the privacy mess that is Discord.

I try my best to explain and contextualize things to users that ask.

You're always welcome to join us in the official Ourcana Discord!

Join the Ourcana Discord Server!

I've been known to yap about strange metaphors though, be warned...

As a small aside, I've been working diligently to incorporate my own security architecture into a hard fork of PluralKit I call "OurKitty". One of the first things I did after patching issues in the security model was go and take a stab at every ask in the old PluralKit server's "suggestions" channel. A few Quality of Life upgrades were easy wins, and I can't wait to provide them to Ourcana users!

It's been quite refreshing to test my own code versus the original in virtual server environments at the scale of a thousand shards and see perf gains in realtime. I'm so excited to release the software once the Ourcana Online launch has settled.

Both Ourcana Online's own Rust server as well as the future OurKitty server release will be available under the AGPL-3.0 (as it should be)! AGPL-3.0 requires offering corresponding source to users who interact with the service over a network. I'm going further: embedding the source directly in the app, so any user can self-host from what they already have rather than chase a link that might disappear.

Stay tuned!

— Heni, Boring Crew System

Heni here, I wanted to write about a key feature of Ourcana online I haven't explained at length. Credit: these images and encryption inventions are from the Willow Project and worm-blossom upstream

With Ourcana, there is no one server. Instead, we use the Willow Protocol and its various sub-and-sister projects to allow for a globally-addressable, universal "space" where any user may carve out their own identity.

End to End Encryption and you

The Willow Protocol project works to enable...

Peer-to-peer protocols which scale up, down, and sideways.

Built out of mathematically secure and sound encryption practices for the modern era, Willow is used by Ourcana to create a set of system, member, and media/journal URLs for users to write system and member data into in a format that all Ourcana and Ourcana-compatible clients and servers understand!

What's in a namespace?

Willow's core principles involve a "namespace" or really a set of all namespaces that are owned by systems or by the community. Users can choose to make some private, or some public, or share data out to only friends in bits and pieces from the entire namespace's virtual filesystem.

These files we see here are real, concrete things users see in Ourcana today such as member data, system data, front history, even down to individual fields such as pronouns or in-system relationships. Journals are stored within the encrypted format as plain markdown files with metadata attached such as "last edited" and "edited by" timestamps and user-data.

Can I keep my data separate?

Users have complete ownership and control of private namespaces by design. Public namespaces are social hangouts and friend exchanges, where everyone logs in via their own "system" address and starts writing into posts on the wider "internet".

This means that telling your friend about a front history change is as simple as the client moving the data around, and then telling all your friends about it!

Can I block users? How do I know who is my friend and who is a hacker/imposter?

Willow has an extension called "Meadowcap" that allows for a server, or really any client, to selectively assign permissions. This means for someone to reach you online in say, ex-system chats, your client must have given them encryption rights (capabilities or "caps") to communicate with you in this way.

This means that bad actors can't pretend to be your friends. They have different keys, different universal system identities, and any junk data that somehow might make it to Ourcana can be discarded without even unwrapping. Users are in full control of whom they communicate with, who can reach them, and how they communicate and where. The server can selectively enforce merely providing any data, while clients retain the information required to decrypt it. In the case of edge services such as Apple Push Notifications integrations (for iOS to tell you who just changed front, for example!) where partial decryption is required, users are presented with options to lower their privacy server-side to enable otherwise impossible features. Meadowcap is expressive enough that one can allow the server to see just the sender and maybe front list of a notification that someone has left a message for them in an internet chat, but not details such as the full contents of said message. Users usually want to know who sent the information, but the message itself can be opened privately local to the device — no need for Apple or anyone else to know what you're yapping about in private, including Ourcana's servers.

This community vs owned namespace layer allows for discovery between friends on Ourcana without them revealing where exactly they may be communicating. One has be aware of a namespace to know to address it, and pull the data from an Ourcana server or peer (friend). Some namespace IDs and subspace IDs are reserved by Ourcana for future online features, such as a collaborative gacha game (free, of course), and leaderboard integrations for collection progress. These are in the application for stealth, and will be provided as a "panic key" system that also has real functionality.

The first Willow Transfer Protocol implementation

I reached out to the Willow and worm-blossom organizations on Discord, where they taught me a lot, such as the value of complex hash algorithms like WILLIAM3 and showed me a draft of the WTP specification. I've spent a few days working on an implementation of their theoretical model towards the goal of making it real. I'm proud to say, I may be the first person on the planet to have a functional WTP server and client that work over the internet today! This, and all other Ourcana server-side code will be available under open source licenses! I hope that publishing rich, developer-friendly specifications may inspire others to write applications similar to Ourcana that have their own take on Plural system management. Imagine a rich ecosystem where all apps can communicate! No more confusion about PluralKit front history versus SP custom fronts... put them all into a unified format and let the client figure out how to present a union of the data.

An atomic resolution model of Conflict-free Resolution Data Types

On the side, I design systems that allow for the ingest of all plural applications' data, so that I can provide the most accurate "source of truth" for a user who may have their information spread over many platforms. Unfortunately, these models get complex and full of jargon (hybrid logical clock? last-write wins? atoms? oh boy...) If you want a preview...

Note: content originally published on Ourcana owner and creator, "Heni's" Patreon found here

In secret, for myself as an Apple Watch user, I've been working on a Watch app that allows for systems to manage their fronts in any way Ourcana can, using the key principle of "pickup interaction size" that Apple designs around in their application stack.

Human design upfront

Apple uses Human Interface Guidelines to communicate intent in a non-verbal language to users that want to discover new features in their apps. One of the ideas here is that users pick up smaller devices that are closer to them before using a larger device for a more complex task. It's trivial to ask your AirPods (and Siri) which are the smallest Apple device "play some Jazz". But maybe it brings up the wrong track... If you wanted more options you'd use your watch to open the Music app and scroll through the recent Jazz and suggested tracks, maybe pick something. Then the music plays on the same AirPods in the end, but one used a bigger device. Scale this up to a phone where one actually wants to search up "Take Five" and perhaps get the perfect track for the moment. That's a pain to do on a Watch, and on Siri one has to have the thought perfectly formed ahead of time.

Ergonomic and detailed

The most ergonomic interfaces are those that follow this flow. With the Ourcana Watch app, I wanted to model two key user interactions as easy and valuable

View front, change, front

This means add to front operations on members, or change and remove with granular control

I added timers and indicators for a summary of key information at a glance

Watch Complications will come soon to put primary/secondary/aux fronters or more on display if there is room on larger ones onto watchfaces and widgets, including user-provided images and local data

Search, browse, and manage members

All the Ourcana data is presented in some way in a search interface I've written that models Ourcana's filtering settings, and includes an instant "heuristic" mode that weights fronters that front more often or have fronted more frequently in the last entries of the front logs

All this data is computed and indexed locally and on-device only. Profile pictures are automatically resized and converted to WatchOS-native format, and all markdown and formatting elements in Ourcana's iOS app are redrawn within the WatchOS app in some way. Even fonts and iCloud sync transfer with a paired iOS app. Even without an iPhone, the Ourcana Watch app can use a stored PluralKit token (or in the future an Ourcana server login) to reach out over Wi-Fi or cellular to update front statuses globally online with one tap

Here's a sneak preview!

a member in the app

The same member in front in the Watch app

Descriptions on watch transfer over with best-effort

Custom fields in the app...

Perfectly translated on your wrist

Simple stats and actions with more to come as the app evolves

Availability

The Ourcana WatchOS app will be available on iOS as an in-app purchase. For those interested and who have a need I can create redemption codes to unlock the app for no cost. Stay tuned for a future release of this and other work I've had cooking!

Ourcana ("Our Arcana") is a Plural System tracker app for managing a collection of members (which can be alters, original characters, personalities, etc). We support Web, iOS/iPadOS/macOS, and Android with Linux and Windows support soon to come!

Features

Track your system members, which of them are fronting (if any, or even all of them!), and use markdown to log journals, design rich profiles (with formatting, style elements, and inline media) and track relationships and interactions between all your system's members.

Ourcana has been tested with up to 20 thousand members. My partner is polyfrag, and I'm learning I probably am too, so this is a top priority!

Theming

Ourcana's design and UX allude to classic card decks, fantasy fortune-telling, and medieval alchemy and magic with the "Tarot" and its "Major Arcana" cards as a for-fun, lighthearted theme to manage character, system, member, and group data. One can change all the terms inside the app however they'd like in settings such as "deck, "member", "system", "fronting", etc.

Color highlights, accents, light and dark mode, and more are all customizable in-app with a rich UI. PluralKit and SimplyPlural color settings transfer automatically!

Integrations

Import from SimplyPlural, import and sync data (or active members) with PluralKit, or manage all your data entirely offline with exported copies of your whole "deck"!

PluralKit synchronization is a first-class feature, with sufficient functionality to completely replace the PK dashboard down the line. Deeper PluralKit-specific integration features will launch with our 1.0.0 online update, so stay tuned!

Accessibility

This application is made with accessibility and ergonomics in mind. I've developed it for my own online community first and many others adjacent to it all over the net known as the "plural" community. As a journal and personal tracking app, Ourcana keeps all your data private, personal, and offline-first by design. Journals are only stored on the device itself, and the sync settings allow one to choose which other data (if any) to share with PluralKit.

Privacy

While currently local-only, Ourcana will soon move to include optional, "online" features. As the lead of my development team, I've worked on End-to-End Encrypted systems such as Matrix.org, FluffyChat, as well as code for the US Government once upon a time. Ourcana is zero-trust by design. That's to say, there's no chance of spying, snooping on data from the server side, or your system data being compromised by a third party through network sniffing and forensics.

As a transfemme system in the United States, and with a partner system who is queer and plural in a hostile nation overseas, I'm committed to security-driven design upfront. System data can be as personal and damaging as ones' literal medical records, so we value the importance of privacy at Ourcana.

How to get it!

Ourcana is on the App Store for iOS and will be released on the Google Play Store for Android before June 1st.

Ourcana is priced at $1 to support the development team, but can be found for free, forever through these resources:

Android APK packages on our Discord server

The website build at https://ourcana.space/

Apple TestFlight builds for iOS

I hope you love it!

I made it for you! <3