CraysPyramid
Pyramid is not a client you install to scroll a feed. It is a relay you run when a community wants its own Nostr territory: membership, invitations, sub-relays, group moderation, media, search and house rules under one owner-operated server.
A relay that behaves like a community
Most people learn Nostr by hearing the four-word model: keys, clients, relays, events. It is a beautiful simplification. It is also the moment where relays get flattened into plumbing. A relay receives events and serves events. Fine. But once a community starts to use Nostr seriously, the relay stops feeling like a pipe and starts feeling like a place. Who can post here? Who can read the private room? What gets moderated? What counts as spam? Who can invite new members? Who has the right to remove someone who is making the room worse?
Pyramid is built for that second question. It is a Nostr relay by fiatjaf, described in the public README as a hierarchical relay system for building and nurturing communities. Fiatjaf's own tools page calls it a Nostr community-driven relay inspired by lobste.rs. That comparison is useful. Lobste.rs is not just a link dump; it is a small social machine with invitations, reputation, moderation and a culture. Pyramid tries to bring that kind of deliberate social architecture into Nostr relay operation.
This matters because Nostr has two opposite dangers. One danger is centralization: a giant platform quietly decides what everyone sees. The other danger is shapelessness: everything is technically open, but no one can create a room with enough trust to become useful. Pyramid is interesting because it does not pretend that governance disappears. It says the quiet part out loud: if you run a community relay, you are building a governed space. The better question is whether the rules are legible, local and controlled by people who actually care about the room.
That is why Pyramid belongs on the app shelf even though it is not a consumer client. It is a product for operators. A club, small publication, research circle, local scene, fan group, venue, collective or Nostr-native association could run it as its own community surface. Members keep their Nostr keys. Events remain Nostr events. But the relay adds a social boundary, and that boundary is the product.
The ladder is the social model
Pyramid's central idea is its membership ladder. Members can invite other members. The number of invites can be configured. A member is responsible for their children and descendants, and can drop them later. The project keeps a log of invites and drops so the community can rebuild state and understand what happened. A person can also be invited by more than one parent at the same time, which makes them less vulnerable to one future parent becoming unreasonable.
This is a very different moderation model from a flat allowlist. A flat allowlist says: these public keys are in, those public keys are out. Pyramid asks who vouched for whom. That creates social accountability without requiring one all-seeing admin to judge every single relationship. If a branch of the tree becomes noisy, dishonest or abusive, the community can trace the branch. If someone is valuable but one relationship breaks, multiple parents can keep them from being casually erased.
The code reflects that model. `pyramid/members.go` keeps a map of members, tracks invite and drop actions, checks whether a public key is a member, calculates children, invite counts and per-level invite limits, and even ties Blossom upload limits to membership level. `management.go` exposes NIP-86-style management handlers: allow a pubkey, ban a pubkey, list allowed pubkeys, list banned pubkeys and ban events. Those calls require authentication through Khatru. This is important because management is not just a decorative UI. It is wired into Nostr relay management conventions.
The human consequence is bigger than the code. Pyramid gives a community a way to grow without opening the gates to every drive-by account. It also avoids making the root admin the only social immune system. The ladder can scale because responsibility is distributed. That is a rare Nostr design move: not just decentralizing data transport, but decentralizing community maintenance.
The risk is obvious too. A ladder can become a caste system if the people at the top forget why the room exists. Invites can become politics. Drops can become revenge. Pyramid does not magically solve human governance. It gives a community a more explicit tool for it. That is already better than pretending tools are neutral while power collects in private chats.
One server, many rooms
Pyramid's second big idea is the sub-relay. One server can expose multiple relay surfaces, each listening on its own HTTP path and behaving like its own room. The README says storage is shared in a single memory-mapped file for fast access and disk-saving deduplication, while indexes remain independent so events do not mix by accident. That is the right mental model: one building, many doors, different rules behind each door.
The main relay is the base room. Only members can publish, and the README notes that it also accepts zaps issued by relay members even when the zap is signed by a zapper service. The internal relay is private to members for reading and writing, which makes it useful for meta discussion. Favorites is a curated room where members can republish chosen external notes. Inbox is a safe receiving room with protection against hellthreads and spam; it filters out people outside the extended two-level social graph of relay members, supports custom bans and can require proof of work.
Then there are algorithmic and moderated surfaces. Popular is automatically curated from member reactions and interactions. Uppermost is for notes loved by a higher percentage of members. Moderated is open to the public but requires Pyramid members to approve posts. Personal is a private note-taking service where each member can read only their own notes. These are not ordinary timeline filters. They are different relay contracts.
The groups relay brings NIP-29-style group behavior into the same world. Members can create groups and become admins. Non-members can join if group admins allow it. Groups can be private, and private groups require authentication and membership to read. The code in `groups/process-event.go` processes NIP-29 moderation actions, creates group state, applies actions and can delete group events. `groups/filter.go` rejects unauthenticated reads into private groups or reads by people who are not members of that group. That gives the relay a group-chat/community layer without leaving Nostr's event model.
This is where Pyramid becomes more than a relay implementation. It is a small civic operating system. A community can have an outer public door, an inner member room, a curated shelf, a spam-resistant inbox, private groups, a public moderated room and personal note storage. If you have ever watched an online community collapse because every conversation happened in the same channel with the same rules, you can feel why that matters.
Services around the relay
Pyramid also bundles services that make a relay feel like a home rather than a daemon. The README lists member statistics, community-linked NIP-05 addresses, NIP-34 GRASP support, negentropy sync, a Blossom media server and paywall functionality. That is a lot, but it is not random. These are the things a community operator asks for after the first week.
Statistics let members see event counts by kind and let the community view usage across the main relay and sub-relays. Search can be enabled with NIP-50, and the search code uses Bleve with multiple language analyzers and a list of indexable event kinds including ordinary notes, group events and long-form kind 30023. That turns the relay into an archive you can actually query.
NIP-05 addresses let each member claim a community-linked Nostr address. That is socially important. A relay can be infrastructure, but an address turns it into identity. It says: this person belongs enough here to carry the community name in their Nostr identity.
GRASP support brings in NIP-34 git behavior. The Dockerfile even installs `git` in the runtime image because the GRASP feature shells out to git commands such as bare repo initialization and pack handling. That tells you Pyramid is not only imagining social posts. It is imagining communities that may host code-related Nostr events too.
Blossom is the media layer. Pyramid's Blossom handler creates a blob directory under the data path, wraps the event store as a blob index, requires authentication, restricts uploads to Pyramid members, applies per-member upload limits and lets users view or delete media. The owner can manage blobs through an included FTP/SFTP server. Again, the pattern is local sovereignty with local administration. Media does not magically become free; someone runs the storage, sets limits and handles abuse.
Negentropy sync, based on NIP-77, lets operators fetch missing events from remote relays or publish missing events to a remote relay. That is a quiet but powerful feature. Relays are not only live sockets; they are archives. Sync is how a community thinks about migration, backup and continuity.
The paywall feature is stranger and worth watching. Pyramid can configure a hashtag, a satoshi amount and a period in days. Member notes with a special tag and hashtag can be marked as paid, and readers only see them if they have zapped the member enough during the configured period. Normal zaps and nutzaps are supported, sourced from the inbox relay. That is not a universal answer to creator monetization, but it is a very Nostr-shaped experiment: access as a local relay rule, based on signed payment-like social events.
The stack and the install
Pyramid is written in Go and released under the Unlicense. GitHub metadata showed the repository `fiatjaf/pyramid`, default branch `master`, created on May 3, 2025, pushed on June 6, 2026, with Go as the primary language when checked. The description is proudly weird: "a wondrous furnace of communityzenship backed by a dynamic ladder of socialhood." Under the joke is a serious codebase.
The Go module lists `fiatjaf.com/nostr`, Khatru, NIP-29 support, Pomegranate, Promenade, Templ, Bleve, LiveKit, SFTP, charts, system stats and many supporting libraries. The Dockerfile builds Tailwind CSS in a Node stage, generates Templ templates in a Go 1.26 builder, then produces a static Pyramid executable and runs it in Ubuntu with `git`, `ca-certificates` and `tzdata`. That shape matches the product: a Go relay with a real web UI, not a JavaScript app pretending to be a relay.
The easy install script is deliberately blunt. It opens HTTP and HTTPS in UFW, fetches the latest GitHub release, picks `amd64` or `arm64`, downloads the binary into a `pyramid` directory, installs a systemd service, sets `HOST=0.0.0.0` and `PORT=443`, enables and starts the service, writes a small message of the day and prints the server IP with setup instructions. The README says that if you can buy VPS access, you can set one up. That is the target: not only professional sysadmins, but people willing to run a small community server.
The project also has a Docker path. The Dockerfile defaults to `PORT=3334`, `DATA_PATH=./data` and `NO_AUTO_UPDATES=true`. That gives operators another deployment style if they prefer containers or want explicit update control. The single-line install is friendly; the Dockerfile is the grown-up fallback.
There is a beautiful tension here. Pyramid wants nontechnical community operators to get running quickly, but it is still infrastructure. You are running a public server, accepting websocket connections, moderating content, storing events, possibly storing blobs, possibly exposing groups and search, and possibly connecting payment-like access rules. The install can be five minutes. The responsibility is not.
What to test before you run one
If Pyramid sounds exciting, do not start by migrating your whole community. Rent a small VPS, install it, and treat the first relay as a rehearsal. Set the relay name, description, icon and contact. Check the NIP-11 relay information document. Invite a second key. Drop that key. Invite it through another parent. Look at the invite/drop log and make sure the ladder behaves the way your community would expect.
Then test the rooms. Publish as a member to the main relay. Try publishing as an outsider and confirm rejection. Open the internal relay and make sure only members can read. Put an external note into favorites. Send noisy mentions into the inbox and watch the filters. Create a group, make it private, then try reading it unauthenticated. Try a moderated post and approve it. Enable search only after you understand the cost and the indexable kinds.
Test services separately. Claim a NIP-05 address. Upload a small file to Blossom as a member and as a non-member. Check member upload limits. Try a sync with a remote relay using harmless data. If you are tempted by paywalls, test with tiny zaps and a test hashtag before promising paid access to anyone. If you enable GRASP, remember that you are now running git-related infrastructure too.
Most important, decide your governance before the software makes decisions for you. Who is the root admin? How many invites does each level get? What behavior gets someone dropped? Can a person appeal through another parent? Who moderates public posts? What is private? What gets backed up? What happens if the VPS bill fails? Pyramid gives you knobs, but knobs are not policy. The policy is yours.
That is why Pyramid is one of the more original entries in this hub. It does not ask, "Can Nostr become another global social feed?" It asks whether small communities can run their own social infrastructure without leaving the Nostr event model. For Crays, that question is alive: venues, member circles, local operators and creator groups need rooms, not only profiles. Pyramid is rough-edged, opinionated and very much a builder's tool. But it points at a serious future: Nostr relays as places people can govern together.
Sources worth opening
This article is based on Pyramid's README, source code, package metadata and the protocol documents behind its management, group, search and sync features.
- fiatjaf/pyramid repository
- Pyramid README
- Pyramid easy install script
- Pyramid Dockerfile
- Pyramid go.mod
- Pyramid frontend package.json
- Core relay rejection logic
- NIP-86 management handlers
- Membership ladder code
- Inbox sub-relay code
- Internal sub-relay code
- Favorites sub-relay code
- Moderated relay code
- NIP-29 groups handler
- NIP-29 group event processing
- Private group access filtering
- Blossom media handler
- Pyramid paywall logic
- GRASP / NIP-34 handler
- Search service code
- Negentropy sync code
- fiatjaf tools page
- Pyramid on pkg.go.dev
- NostrApps listing for Pyramid
- NIP-11 relay information document
- NIP-29 relay-based groups
- NIP-34 git stuff
- NIP-50 search capability
- NIP-77 negentropy syncing
- NIP-86 relay management API
