ManiMe

by ManiMe Sep 3, 2025 · Edited

Non-Custodial Social Apps

A "social app" is any app that allows users to interact. If it processes user accounts and data without controlling them, it may be considered a “non-custodial social app”. Nostr is currently the only protocol that supports interoperability between non-custodial social apps. While not all apps on Nostr are non-custodial, the Nostr protocol makes it easy and profitable for social apps to reduce custody of users and their data while increasing their access to an entire network of new users and novel data.

by ManiMe Jun 5, 2025 · Edited

Nostr for Social Apps

Nostr is NOT a social network. Nostr is a network of interconnected social apps. And, since any app is a social app, Nostr is for every app.

by ManiMe Apr 9, 2025 · Edited

Nostr for Business Apps

Businesses want Nostr, but Nostr is not ready for business. What can be done?

by ManiMe Mar 12, 2025 · Edited

Webs of Trust Onboarding and Discovery

For over a year, I have been developing “webs of trust onboarding and discovery” tools for Nostr. With additional funding, I hope to continue this endeavor. Here is my 2025 application for grant funding.

by ManiMe Jun 24, 2024 · Edited

Social Onboarding is Nostr’s Superpower

Anyone who thinks that “onboarding new users” is simply a technical challenge of educating people about “how Nostr works”, is grossly mistaken about social networks in general and blind to what makes Nostr so special.

by ManiMe May 13, 2024 · Edited

Meet Me On Nostr : alpha-0.4 release

Project summary and release notes.

by ManiMe Jan 30, 2024 · Edited

Sovereign Webs of Trust

Sovereign WoT on Nostr begins with a single assertion : _”Users should be able to control which accounts are trusted and how content is fed to them … across any client.”_ The rest is up to us…

by ManiMe Jul 16, 2000 · Edited

An Open Architecture for Content Types on Nostr

Nostr is a protocol for communicating events between clients and relays. Events can be anything from adding posts, deleting posts, reacting to posts, editing profiles, and on and on. Each kind of event is designated by a “kind number”. Even different types of user generated content get their own “kind number”. In theory, any client or relay can send or receive (or invent) any event kind number. In practice, however, new kind numbers for events are designated by adding a NIP to the protocol. In this way, developers can coordinate with each other to build clients and relays that work well together. But clients and relays should have the freedom to update and invent new content types for novel use cases. They are the front line of “great user experiences”, and should be able to share new and needed content types with each other “ad hoc”, without having to be “approved” by the NIP standards. This article explains why we should care, and how to resolve this conundrum with minimal fuss, before it gets out of hand.