Run a Community App for Free with Nostr

Tldr

• Nostr is a new open social protocol for the internet
• You can use it to create your own online community website/app for your users
• This needs only a few simple components that are free and open source
• Jumble.Social client is a front-end for showing your community content to your users
• Simple With Whitelist relay (SW2) is a back-end with simple auth for your community content
• In this blog I explain the components and set up a online community website/app that any community or company can use for their own users, for free.

You Can Run Your Own Private "X" For Free

Nostr is a new open social protocol for the internet. Because it is a protocol it is not controlled by any one company, does not reside on any one set of servers, does not require any licenses, and no one can stop you from using it however you like.

When the name Nostr is recognised, it is as a "Twitter/X alternative" – that is an online open public forum. Nostr is more than just this. The open nature of the protocol means that you can use it however you feel like, including that you can use it for creating your own social websites to suit whatever goals you have – anything from running your own team collaboration app, to running your own online community.

Nostr can be anything – not just an alternative to X, but also to Slack, Teams, Discord, Telegram (etc) – any kind of social app you'd like to run for your users can be run on Nostr.

In this blog I will show you how to launch your own community website, for your community members to use however they like, with low code, and for free.

Simple useful components

Nostr has a few simple components that work together to provide your experience –

• Your "client" – an app or a website front-end that you log into, which displays the content you want to see
• Your "relay" – a server back-end which receives and stores content, and sends it to clients
• Your "user" – a set of keys which represents a user on the network,
• Your "content" – any user content created and signed by a user, distributed to any relay, which can be picked up and viewed by any client.

It is a pattern that is used by every other social app on the internet, excepting that in those cases you can usually only view content in their app, and only post your content to their server.

Vs with Nostr where you can use any client (app) and any relay (server), including your own.

This is defined as a standard in NIP-01 which is simple enough that you can master it in a weekend, and with which you can build any kind of application.

The design space is wide open for anyone to build anything–

• Clones of Twitter, Instagram, Telegram, Medium, Twitch, etc,
• Whole new things like Private Ephemeral Messengers, Social Podcasting Apps, etc,
• Anything else you can dream up, like replacements for B2B SaaS or ERP systems.

Including that you can set up and run your own "X" for your community.

Super powers for –private– social internet

When considering my use of social internet, it is foremost private not public. Email, Whatsapp, Slack, Teams, Discord, Telegram (etc), are all about me, as a user, creating content for a selected group of individuals – close friends, colleagues, community members – not the wider public.

This private social internet is crying out for the kind of powers that Nostr provides. The list of things that Nostr solves for private social internet goes on-and-on.

Let me eat my own dog food for a moment.

• I am a member of a community of technology entrepreneurs with an app for internal community comms. The interface is not fit for this purpose. Good content gets lost. Any content created within the walled kingdom cannot be shared externally. Community members cannot migrate to a different front-end, or cross-post to public social channels.
• I am a member of many communities for kids social groups, each one with a different application and log in. There is no way to view a consolidated feed. There is no way to send one message to many communities, or share content between them. Remembering to check every feed separately is a drag.
• I am a member of a team with an app for team comms. It costs $XXX per user per month where it should be free. I can't self-host. I can't control or export my data. I can't make it interoperate natively with other SaaS. All of my messages probably go to train a Big Co AI without my consent.

In each instance "Nostr fixes this."

Ready now for low-code admins

To date Nostr has been best suited to a more technical user. To use the Nostr protocol directly has been primarily a field of great engineers building great foundations.

IMO these foundations are built. They are open source, free to use, and accessible for anyone who wants to create an administer their own online community, with only low code required.

To prove it, in this blog I will scratch my own itch. I need a X / Slack / Teams alternative to use with a few team members and friends (and a few AIs) as we hack on establishing a new business idea.

I will set this up with Nostr using only open source code, for free.

Designing the Solution

I am mostly non-technical with helpful AI. To set up your own community website in the style of X / Slack / Teams should be possible for anyone with basic technology skills.

• I have a cheap VPS which currently runs some other unrelated Nostr projects in Docker containers,
• My objective was to set up and run my own community website for my own team use, in Docker, hosted on my own server.

User requirements

What will I want from a community website?

• I want my users to be able to log into a website and post content,
• I want to save that content to a server I control accessed only be people I authorise,
• I want my users to view only that content by default, and not be exposed to any wider public social network unless they knowingly select that,
• I want my user's content to be either:
  • a) viewable only by other community members (i.e. for internal team comms), or
  • b) by the wider public (i.e. for public announcements), at the user's discretion.
• I want it to be open source so that other people maintain the code for me,
• I want it for free.

Nostr solutions

To achieve this with Nostr, I'll need to select some solutions "a-la carte" for each of the core components of the network.

• A client – For my client, I have chosen Jumble. Jumble is a free open-source client by Cody Tseng, available free on Github or at Jumble.social. I have chosen Jumble because it is a "relay-centric" client. In key spots the user interface highlights for the user what relay they are viewing, and what relay they are posting to. As a result, it is a beautiful fit for me to use as the home of all my community content.
• A relay – For my relay, I have chosen Simple With Whitelist (SW2). SW2 is a free open-source relay by Utxo The Webmaster, based on Khatru by Fiatjaf, available free on Github. I have chosen SW2 because it allows for very simple configuration of user auth. Users can be given read access to view notes, and write access to post notes within simple config.json files. This allows you to keep community content private or selectively share it in a variety of ways. Per the Nostr protocol, your client will connect with your relay via websocket.
• A user sign-up flow – Jumble has a user sign-up flow using Nstart by Fiatjaf, or as an admin I can create and provision my own users with any simple tool like NAK or Nostrtool.
• A user content flow – Jumble has a user content flow that can post notes to selected relays of the users choice. Rich media is uploaded to free third-party hosts like Nostr.build, and in the future there is scope to self-host this too.

With each of these boxes ticked I'm ready to start.

Launching a Private Community Website with Jumble and SW2

Install your SW2 relay

The relay is the trickiest part, so let's start there. SW2 is my Nostr relay software of choice. It is a Go application and includes full instructions for Go install. However, I prefer Docker, so I have built a Docker version and maintain a Docker branch here.

1 – In a terminal clone the repo and checkout the Docker branch

git clone https://github.com/r0d8lsh0p/sw2.git
cd sw2
git checkout docker

2 – Set up the environment variables

These are specified in the readme. Duplicate the example .env file and fill it with your variables.

cp .env.example .env 

For me this .env file was as follows–

# Relay Metadata
RELAY_NAME="Tbdai relay"
RELAY_PUBKEY="ede41352397758154514148b24112308ced96d121229b0e6a66bc5a2b40c03ec"
RELAY_DESCRIPTION="An experimental relay for some people and robots working on a TBD AI project."
RELAY_URL="wss://assistantrelay.rodbishop.nz"
RELAY_ICON="https://image.nostr.build/44654201843fc0f03e9a72fbf8044143c66f0dd4d5350688db69345f9da05007.jpg"
RELAY_CONTACT="https://rodbishop.nz"

3 – Specify who can read and write to the relay

This is controlled by two config files read_whitelist.json and write_whitelist.json.

• Any user with their pubkey in the read_whitelist can read notes posted to the relay. If empty, anyone can read.
• Any user with their pubkey in the write_whitelist can post notes to the relay. If empty, anyone can write.

We'll get to creating and authorising more users later, for now I suggest to add yourself to each whitelist, by copying your pubkey into each JSON file. For me this looks as follows (note, I use the 'hex' version of the pubkey, rather than the npub)–

{
  "pubkeys": [
    "1bda7e1f7396bda2d1ef99033da8fd2dc362810790df9be62f591038bb97c4d9"
  ]
}

If this is your first time using Nostr and you don't yet have any user keys, it is easy and free to get one. You can get one from any Nostr client like Jumble.social, any tool like NAK or nostrtool.com or follow a comprehensive guide like my guide on mining a Nostr key.

4 – Launch your relay

If you are using my Docker fork from above, then–

docker compose up

Your relay should now be running on port 3334 and ready to accept web socket connections from your client.

Before you move on to set up the client, it's helpful to quickly test that it is running as expected.

5 – Test your websocket connection

For this I use a tool called wscat to make a websocket connection.

You may need to install wscat, e.g.

npm install -g wscat

And then run it, e.g.

wscat -c ws://localhost:3334

(note use ws:// for localhost, rather than wss://).

If your relay is working successfully then it should receive your websocket connection request and respond with an AUTH token, asking you to identify yourself as a user in the relay's read_whitelist.json (using the standard outlined in NIP-42), e.g.

Connected (press CTRL+C to quit)
< ["AUTH","13206fea43ef2952"]

>

You do not need to authorise for now.

If you received this kind of message, your relay is working successfully.

Set a subdomain for your relay

Let's connect a domain name so your community members can access your relay.

1 – Configure DNS

At a high level –

1. Get your domain (buy one if you need to)
2. Get the IP address of your VPS
3. In your domain's DNS settings add those records as an A record to the subdomain of your choice, e.g. relay as in relay.your_domain_name.com, or in my case assistantrelay.rodbishop.nz

Your subdomain now points to your server.

2 – Configure reverse proxy

You need to redirect traffic from your subdomain to your relay at port 3334.

On my VPS I use Caddy as a reverse proxy for a few projects, I have it sitting in a separate Docker network. To use it for my SW2 Relay required two steps.

First – I added configuration to Caddy's Caddyfile to tell it what to do with requests for the relay.your_domain_name.com subdomain. For me this looked like–

assistantrelay.rodbishop.nz {
  reverse_proxy sw2-relay:3334 {
    # Enable WebSocket support
    header_up X-Forwarded-For {remote}
    header_up X-Forwarded-Proto {scheme}
    header_up X-Forwarded-Port {server_port}
  }
}

Second – I added the Caddy Docker network to the SW2 docker-compose.yml to make it be part of the Caddy network. In my Docker branch, I provide this commented section which you can uncomment and use if you like.

services:
  relay:
     ... relay configuration here ...
#    networks:
#      - caddy # Connect to a Caddy network for reverse proxy

# networks:
#  caddy:
#    external: true # Connect to a Caddy network for reverse proxy

Your relay is now running at your domain name.

Run Jumble.social

Your client set up is very easy, as most heavy lifting is done by your relay. My client of choice is Jumble because it has features that focus the user experience on the community's content first. You have two options for running Jumble.

1. Run your own local copy of Jumble by cloning the Github (optional)
2. Use the public instance at Jumble.social (easier, and what we'll do in this demo)

If you (optionally) want to run your own local copy of Jumble:

git clone https://github.com/CodyTseng/jumble.git
cd jumble
npm install
npm run dev

For this demo, I will just use the public instance at http://jumble.social

Jumble has a very helpful user interface for set up and configuration. But, I wanted to think ahead to onboarding community members, and so instead I will do some work up front in order to give new members a smooth onboarding flow that I would suggest for an administrator to use in onboarding their community.

1 – Create a custom landing page URL for your community members to land on

When your users come to your website for the first time, you want them to get your community experience without any distraction. That will either be–

1. A prompt to sign up or login (if only authorised users can read content)
2. The actual content from your other community members (If all users can read content)

Your landing page URL will look like: http://jumble.social/?r=wss://relay.your_domain_name.com

• http://jumble.social/ – the URL of the Jumble instance you are using
• ?r= – telling Jumble to read from a relay
• wss:// – relays connect via websocket using wss, rather than https
• relay.your_domain_name.com – the domain name of your relay

For me, this URL looks like http://jumble.social/?r=wss://assistantrelay.rodbishop.nz

2 – Visit your custom Jumble URL

This should load the landing page of your relay on Jumble.

In the background, Jumble has attempted to establish a websocket connection to your relay.

If your relay is configured with read authentication, it has sent a challenge to Jumble asking your user to authenticate. Jumble, accordingly should now be showing you a login screen, asking your user to login.

3 – Login or Sign Up

You will see a variety of sign up and login options. To test, log in with the private key that you have configured to have read and write access.

In the background, Jumble has connected via websocket to your relay, checked that your user is authorised to view notes, and if so, has returned all the content on the relay. (If this is your first time here, there would not be any content yet).

If you give this link to your users to use as their landing page, they will land, login, and see only notes from members of your community.

4– Make your first post to your community

Click the "post" button and post a note. Jumble offers you the option to "Send only to relay.your_domain_name.com".

• If set to on, then Jumble will post the note only to your relay, no others. It will also include a specific tag (the "-" tag) which requests relays to not forward the note across the network. Only your community members viewing notes on your community relay can see it.
• If set to off, then Jumble will post the note to your relay and also the wider public Nostr network. Community members viewing notes on the relay can see it, and so can any user of the wider Nostr network.

5– Optional, configure your relay sets

At the top of the screen you should now see a dropdown with the URL of your relay.

Each user can save this relay to a "relay set" for future use, and also view, add or delete other relays sets including some sets which Jumble comes with set up by default.

As an admin you can use this to give users access to multiple relays. And, as a user, you can use this to access posts from multiple different community relays, all within the one client.

Your community website is up and running

That is the basic set up completed.

• You have a website where your community members can visit a URL to post notes and view all notes from all other members of the community.
• You have basic administration to enforce your own read and write permissions very simply in two json files.

Let's check in with my user requirements as a community admin–

• My community is saving content to a server where I control access
• My users view only that content by default, and are not exposed to any wider public social network unless they knowingly select that
• My user's content is a) viewable only by other community members, or b) by the wider public, at the user's discretion
• Other people are maintaining the code for me
• It's free

This setup has scope to solve my dog fooding issues from earlier–

• If adopted, my tech community can iterate the interface to suit its needs, find great content, and share content beyond the community.
• If adopted, my kids social groups can each have their own relays, but I can post to all of them together, or view a consolidated feed.
• If adopted, my team can chat with each other for free. I can self host this. It can natively interoperate with any other Nostr SaaS. It would be entirely private and will not be captured to train a Big Co AI without my consent.

Using your community website in practice

An example onboarding flow

1. A new member joins your IRL community
2. Your admin person gives them your landing page URL where they can view all the posts by your community members – If you have configured your relay to have no read auth required, then they can land on that landing page and immediately start viewing your community's posts, a great landing experience
3. The user user creates a Nostr profile, and provides the admin person with their public key
4. The admin person adds their key to the whitelists to read and write as you desire.

Default inter-op with the wider Nostr network

• If you change your mind on SW2 and want to use a different relay, your notes will be supported natively, and you can migrate on your own terms
• If you change your mind on Jumble and want to use a different client, your relay will be supported natively, and you can migrate on your own terms
• If you want to add other apps to your community's experience, every Nostr app will interoperate with your community by default – see the huge list at Awesome Nostr
• If any of your users want to view your community notes inside some other Nostr client – perhaps to see a consolidated feed of notes from all their different communities – they can.

For me, I use Amethyst app as my main Nostr client to view the public posts from people I follow. I have added my private community relay to Amethyst, and now my community posts appear alongside all these other posts in a single consolidated feed.

Scope to further improve

• You can run multiple different relays with different user access – e.g. one for wider company and one for your team
• You can run your own fork of Jumble and change the interface to suit you needs – e.g. add your logo, change the colours, link to other resources from the sidebar.

Other ideas for running communities

• Guest accounts: You can give a user "guest" access – read auth, but no write auth – to help people see the value of your community before becoming members.
• Running a knowledge base: You can whitelist users to read notes, but only administrators can post notes.
• Running a blind dropbox: You can whitelist users to post notes, but only the administrator can read notes.
• Running on a local terminal only: With Jumble and SW2 installed on a machine, running at – localhost:5173 for Jumble, and localhost:3334 for SW2 you can have an entirely local experience at http://localhost:5173/?r=ws://localhost:3334.

What's Next?

In my first four blogs I explored creating a good Nostr setup with Vanity Npub, Lightning Payments, Nostr Addresses at Your Domain, and Personal Nostr Relay.

Then in my latest three blogs I explored different types of interoperability with NFC cards, n8n Workflow Automation, and now running a private community website on Nostr.

For this community website–

• There is scope to make some further enhancements to SW2, including to add a "Blossom" media server so that community admins can self-host their own rich media, and to create an admin screen for administration of the whitelists using NIP-86.
• There is scope to explore all other kinds of Nostr clients to form the front-end of community websites, including Chachi.chat, Flotilla, and others.
• Nostr includes a whole variety of different optional standards for making more elaborate online communities including NIP-28, NIP-29, NIP-17, NIP-72 (etc). Each gives certain different capabilities, and I haven't used any of them! For this simple demo they are not required, but each could be used to extend the capabilities of the admin and community.

I am also doing a lot of work with AI on Nostr, including that I use my private community website as a front-end for engaging with a Nostr AI. I'll post about this soon too.

Please be sure to let me know if you think there's another Nostr topic you'd like to see me tackle.

GM Nostr.