Identity Revisited: Building a Pseudonymous Publishing Presence

Rationale

Today I decide to write under the pseudonym Shakespear. I want readers to recognize my work across a website and several publishing platforms. I want to retain control of that presence, recover from failures, and keep it separate from my other life. What must I establish, and what must I keep maintaining?

Choosing the name is easy. Building a lasting publishing presence around it involves accounts, keys, profiles, places to publish, ways to be found, and arrangements for recovering access when something goes wrong. Over time, that presence accumulates work, relationships, and a reputation that I want to preserve even as its technical foundations change.

In my recent articles about Nostr, Hive, and Arweave and AR.IO, identity kept coming up in different forms: public keys, accounts, signing authorities, and names pointing to published work. Each ecosystem has its own mechanisms, but I want to use them as parts of one coherent publishing activity. The POSSE principle (Publish on your Own Site, Syndicate Elsewhere) makes this especially concrete: each “elsewhere” brings another set of identity and access arrangements into the picture.

Some connections between those presences should be public. A reader who finds Shakespear on one platform should be able to discover the author’s website and other accounts, perhaps through a simple linktree-style directory. I may want to keep other connections private, including those to my everyday accounts, browsing activity, or payment history.

Establishing a pseudonym means deciding which associations to make visible and which separations to maintain.

The immediate motivation for this article is a tool I am developing for independent publishing under the working title Publishing Army Knife, or pak for short. The project uses an identity.yaml file to bring together author information, public identifiers, publishing destinations, and references to credentials. My understanding of that file’s role is still evolving. Writing this article is part of the design work: I want to clarify what the file should describe, how the tools should use it, and how it can help establish and maintain a publishing presence.

My starting point is the publishing setup explored in the recent articles. The examples in the Hive and Arweave articles use ordinary internet connections and, where convenient, credit-card payments. These arrangements are useful starting points for learning the systems and publishing actual work. They also establish associations that later privacy measures cannot simply erase.

Later stages could add guided account creation and profile configuration, followed by a dedicated Incus workstation with its own browser state and publishing tools. The description of the publishing persona would remain separate from the configuration of the machine that provides its working environment. Further along that path, I want to explore enforced privacy routing through NymVPN and payment arrangements using technologies such as shielded Zcash. These are future architectural requirements whose implementation still needs to be worked out. At every stage, everyday work inside the environment has to remain convenient enough that preserving the intended separation becomes the normal way of working.

This article will follow that path as an architecture walkthrough, explaining the responsibilities, dependencies, and design choices, with pointers to possible implementations. I previously explored the broader meaning of identity in Digital Civil Rights and Digital Integrity. That philosophical background matters here: an identity has a continuing history while its state, components, and relationships change. I will develop that argument in an appendix and bring it into the practical discussion where it helps explain the design.

What Must Exist for Shakespear to Publish?

Imagine that a reader discovers one of Shakespear’s essays. They can visit an author page, find earlier work, follow future publications, and get in touch. If they encounter Shakespear again on another platform, they have a way to connect that appearance with the author they already know. Months later, the biography or profile picture may have changed, but the publications and relationships still belong to a recognizable, continuing presence.

For our running example, Shakespear will have a publishing home on the web, a Nostr presence, a Hive account, and an e-mail address for correspondence. The publishing home gives readers a place to return to; the other presences provide additional ways to discover the work, follow the author, and join conversations. The home could use conventional hosting or the storage, gateway, and naming arrangements explored in the Arweave and AR.IO article. We can decide how to provide that home separately from deciding which author persona it represents.

It helps to distinguish four things that are often bundled together under the word “identity”:

The display name “Shakespear” can appear in several profiles even when the underlying account identifiers differ. Changing the biography updates the presentation of an existing presence. Knowing its address lets a reader find it; publishing through it requires the appropriate authority. These distinctions give us a practical starting point for the broader relationship between an entity and the names that refer to it.

The visible profiles are only part of the arrangement. Readers also need ways to discover the work and follow new publications. Someone must maintain the publishing home, operate the mailbox, control the signing credentials, and pay for services where necessary. A first map therefore includes the public presences, routes for discovery, and the relationships that keep them usable:

Shakespear: the author persona
|
+-- Public presences
|   +-- Publishing home: articles, author page, public identity directory
|   +-- Nostr presence: publications, announcements, and conversations
|   +-- Hive account: publications, announcements, and conversations
|   `-- Contact address: correspondence with readers
|
+-- Discovery and following
|   +-- Website feed -> subscribers and feed directories
|   `-- Search engines -> indexed articles and author pages
|
`-- Operating and maintaining those presences
    +-- Hosting and naming accounts -> publishing home
    +-- Mailbox account(s) -> correspondence and selected recovery paths
    +-- Search Console / webmaster accounts -> verification and search diagnostics
    +-- Subscription-service accounts -> feed listings and email delivery
    +-- Signing credentials -> publication through the relevant identities
    `-- Payment arrangements -> services that require funding

This is a map of roles and dependencies; the exact accounts depend on the chosen services. Webmaster tools and hosted subscription services are optional additions, explored in the search and discovery article. Search engines can discover a site without a webmaster account, and readers can subscribe directly to its feed.

A public contact address and an address used for account recovery can be different. If a domain registrar allows password recovery through a mailbox, continued control of that mailbox becomes part of maintaining the publishing home. That is the “skeleton key” relationship discussed in my earlier article on identity and credential management. It belongs in our understanding of the setup even though readers normally have no reason to see it.

What looks like a few publishing destinations quickly becomes a collection of places where information, access, and relationships need to be maintained. Making that manageable is a central purpose of pak: bring the arrangement into one description, guide its setup, and help keep it current. The aim is that an author can operate this presence without having to become an expert in every service.

The public directory we will develop later draws on the associations Shakespear wants readers to know: the website, author profiles, and contact information. The complete operational map may also contain administrative and recovery relationships that should remain private.

Before establishing these relationships, I need to decide how much separation from my other life I want.

• Publishing under a pen name may simply mean that readers see “Shakespear” while service providers know my everyday identity.
• Keeping that connection private from providers, payment services, or observers of network activity is a further requirement.
  It affects the choice of accounts and services, the way they are paid for, and the environment from which they are used.

My earlier discussion of public and private personas already approached this problem through the risk of connecting otherwise separate activities. The reverse-Nextcloud publishing proposal explored a possible architecture for making writing publicly accessible while concealing its publisher’s infrastructure and identity. Here, those concerns meet the concrete task of establishing an author presence. Using an everyday mailbox or payment account may be acceptable for the first version, but those connections become part of its history from the moment they are used.

At this stage, we need a clear map of what Shakespear intends to establish, which associations should be public, and which dependencies sustain the presence. The next step is to understand how the author and the publishing tools obtain the authority to act through each part of that map.

Credentials and Service Dependencies

To publish Shakespear’s essay, a tool needs the relevant public identifier, permission to perform the operation, and access to the services that handle it.

On Nostr, the tool prepares an event, asks a signer to sign it, and sends the signed event to the chosen relays. The signer can keep the private key while allowing the tool to request signatures. That gives us two separate configuration needs: which identity to use and how the tool obtains authority to act through it.

The earlier publishing articles illustrate how these requirements differ:

Payment adds another relationship. In the Arweave walkthrough, the upload signer, the account paying with Turbo credits, and the owner of the ArNS name can differ. Someone can fund Shakespear’s uploads without obtaining the signing key or control of the name. The configuration needs to preserve these distinctions even when one person manages all the roles.

Holding the required credentials also leaves dependencies on the receiving systems. A relay may reject a correctly signed event, and a gateway may decline to serve stored content.

This continues the malicious service provider problem from my earlier privacy article. Proving that I am entitled to request an action and trusting the service to carry it out faithfully are separate concerns. The architecture should make both the authority we hold and the dependencies we accept visible.

For each part of Shakespear’s presence, we therefore need to record which public identifier we use, which operations the tools should be able to perform, and how they obtain the corresponding authority. That is the arrangement our identity configuration needs to express.

Making the Arrangement Explicit: identity.yaml

In the pak (Publishing Army Knife) tool, identity.yaml describes the publishing persona in a form that tools can read. Its schema defines the accepted fields and which ones are required. Currently, the minimum is schema_version and an author section containing a byline; services such as Hive or Nostr are optional. Shakespear can start with that minimum and add information as the presence takes shape:

schema_version: 1
author:
  byline: Shakespear

# Added as the corresponding services are established:
contact:
  email: letters@shakespear.example
website:
  url: https://shakespear.example/
hive:
  account: shakespear-demo
  posting_credential: null

These are existing schema fields with illustrative addresses and an illustrative account name. Here, null means that access to the posting credential is deliberately unconfigured. The file can describe an account before the tools are ready to publish through it. Schema validation checks the structure.

Today, pak identity-sync already uses author.byline to configure the publication builder. A shared biography and additional profile settings are proposed extensions. Recovery and payment relationships also need to be accounted for, but their placement in this file or separate private records remains a design question.

The information has different audiences. The byline, website, and selected profile links can supply a public directory akin to https://linktr.ee/ or https://bio.link/. Signer connections and publication destinations serve the tools; recovery relationships may be private even when they contain no passwords. Publishing that directory therefore means selecting its public fields. Credential references keep secret values outside this file. The current implementation uses KWallet for those references; supporting other storage arrangements is further work.

For now, identity.yaml supports publishing from the computer we already use. A later increment would provide Shakespear with a dedicated Incus workstation, accessed remotely, with its own browser and publishing tools. Its setup would combine persona configuration from identity.yaml with separate workstation configuration for the desktop, storage, and networking.

That provisioning process establishes a starting environment. Months later, Shakespear will have accumulated bookmarks, browser sessions, drafts, credentials, and many small adjustments. A fresh instance created from the original template would not contain those particulars. They are the accumulated state of an environment that has acquired its own history through use.

• Persona configuration: Shakespear’s identifiers, profile information, and connections to publishing services.
• Workstation configuration: the operating system, desktop, storage, remote access, and network policy of the environment used to work as Shakespear.
• Accumulated state: drafts, browser sessions, bookmarks, credentials, and publication records that develop through use and need their own preservation arrangements.

Identity therefore cannot be treated solely as a provisioning job. Preserving the state that develops beyond the standardized starting point is part of sustaining that identity. This is a practical consequence of the philosophical argument we will develop in the appendix: continuity has to accommodate the particulars accumulated over time.

Incus snapshots provide restorable checkpoints of the state stored in the instance. They belong in the design from the beginning: over time, the snapshots themselves become part of the material we maintain for Shakespear, alongside the configuration and the live environment. The snapshot history also needs backups beyond its host, following the backup and restore approach explored in my home-server article. State held by external services still depends on those services and their recovery arrangements.

The schema can evolve as these workflows become clearer. The next step is to connect this description to the operations that establish accounts and maintain their public profiles.

Establishing Accounts and Maintaining Their Profiles

With an initial identity.yaml, Shakespear needs a way to establish each chosen presence and maintain its public presentation. I envisage two operations:

• create establishes an account or cryptographic identity and records its identifiers and credential references.
• configure sets or updates its public profile: display name, biography, picture, website, and related links.

The following commands describe a proposed pak interface:

pak identity nostr create
pak identity nostr configure
pak identity hive create
pak identity hive configure

The work behind create depends on the destination. On Nostr, generating a key pair establishes the identity. On Hive, another account must register the new account on the blockchain. The workflow would record the established results in identity.yaml. Someone bringing an existing account would supply its identifiers and credential references, then proceed to configure.

For the initial profile, Shakespear might choose the display name Shakespear and the biography “Essays and observations.” The proposed shared profile fields would let configure apply this description to the selected services, with adjustments where their profile formats differ. The Nostr profile walkthrough already demonstrates the underlying operation: sign the profile metadata and publish it to relays.

Months later, the writing has found a focus: “Essays about cities and the people who build them.” Shakespear edits the biography in identity.yaml and runs the two configure commands again. Editing the file changes the intended profile locally; the commands must submit the updates using each presence’s authority and report which destinations accepted them.

Similarly, pak identity site create could guide the establishment of the publishing home. That might involve registering a domain and choosing hosting, or using an arrangement such as Arweave with an ArNS name. Some steps could be automated; others could provide instructions to follow in a browser, then help check and record the result. Guided manual steps are part of the intended workflow. The corresponding configure operation would maintain the site’s public author information.

These profiles give readers several places to encounter Shakespear. Their links can then help readers recognize which presences belong together.

Making Shakespear Recognizable Across Platforms

A reader who discovers Shakespear on Hive should be able to find the website, follow new articles, or continue the conversation on Nostr. A public author page can provide that map. I want pak to generate this directory from explicitly selected public information in identity.yaml, supplemented by links supplied by the website, such as its feed. An illustrative page could look like this:

Shakespear
Essays about cities and the people who build them.

Read       https://shakespear.example/
Subscribe  https://shakespear.example/feed.xml
Nostr      Profile link and full public key
Hive       Profile of shakespear-demo
Contact    letters@shakespear.example

This is the linktree idea introduced earlier, hosted as part of the publishing home. The Nostr walkthrough shows how a public key can also be presented as a browser-friendly profile link. The directory generator would use an explicit selection of fields; recovery addresses, credential references, and administrative relationships belong to the operational description.

A shared byline, portrait, and biography help readers recognize Shakespear at each destination. The directory claims that these presences belong together. Links back from the Hive and Nostr profiles provide supporting evidence. On Nostr, that endorsement can appear in signed profile metadata, tying it to the public key. A reader can follow these connections from an address or key they already trust. A copied name, portrait, or biography alone gives an impersonator no such continuity with the established presence.

Following the author also needs a path to new work. When Shakespear publishes another essay, the website’s feed can carry it to subscribers, while short announcements on Nostr and Hive point readers to the article. This continues my earlier ActivityPub experiment and the feed and subscription arrangements already used on this blog. The directory helps readers choose where to follow; feeds and announcements keep that choice useful.

Search and discovery add another route to the work. Search engines can discover linked public pages without a webmaster account. Using Google Search Console, however, introduces a Google account and verification of control over the site. That account belongs on Shakespear’s operational map, including its recovery arrangements. Using an everyday Google account would link Shakespear’s site to that account in Google’s records.

Preserving the Presence Through Change and Failure

Six months into the project, the disk holding Shakespear’s workstation fails. The published essays are still online, but continuing the work now depends on what was preserved elsewhere. Three things contribute differently to recovery:

• Configuration describes the setup to rebuild: tools, settings, public identifiers, and connections to services. A credential reference tells us where to look; it cannot recreate the secret.
• Backed-up state preserves the particulars accumulated through use: drafts, bookmarks, publication records, and locally stored credentials.
• External recovery procedures may restore access to accounts when credentials are unavailable, subject to each service’s rules and the evidence it requires.

In the proposed Incus environment, snapshots would preserve checkpoints of that working history. Copies kept only on the failed storage would be lost with it, so the design also needs backups elsewhere and restore tests on another system. Restoring an older checkpoint does not undo publications or credential changes already made on external services.

A simplified recovery map could look like this:

Backup stored outside the workstation's host
`-- Configuration, working state, and backed-up credentials

Access to recovery mailbox + provider's required checks
+-- Registrar recovery -> domain administration
`-- Hosting recovery -> website administration

The backup and any secret needed to open it must be accessible without the failed machine. The mailbox needs a surviving access or recovery route too. Where a service accepts password resets through e-mail, that mailbox becomes the potential skeleton key discussed in my privacy article. Using a personal mailbox for this purpose connects Shakespear’s account to it in the provider’s records, even if readers never see the address.

Recovery differs between systems. For the Nostr key pair in our walkthrough, losing every usable copy of the secret prevents further signing under that public key; a new key pair establishes a different identifier. Hive’s named account can retain its name while authorized changes replace its keys. Its account-recovery procedure also requires cooperation from the recovery account and proof using a recent owner authority. It cannot simply compensate for losing every credential.

The same dependency map helps with ordinary changes. Moving hosting while retaining the domain can preserve the addresses readers know; that continuity still depends on domain renewal and access to its administration. Where a service supports credential replacement, Shakespear must update it and the local tools while preserving access throughout the change. If a public address or account changes, Shakespear needs to update the directory and reciprocal links, and announce the move through presences readers already recognize.