Learn the fastest way to get started powering global instant payments through the Lightning Network — 1 API away from adding Bitcoin to the fabric of your games, apps, and systems.
As a Bitcoin payments API infrastructure provider, one of the many items we aim to always improve upon is `developer time to payment` — how long does it take for a new ZEBEDEE developer to perform their first global Bitcoin payment?
Because of that, our team is always focused on introducing new ways to quickly get started in a secure server environment and interacting with the ZEBEDEE API or SDKs.
Replit is an online integrated development environment (IDE) that allows users to write, run, and collaborate on code directly from their web browser. Basically, any developer can spin up an entire development environment on the language of their choosing, and go from first code commit to full production deployment all in the same web interface.
Add the flexibility developers have with cloud-based IDEs like Replit, to the simplicity of the ZEBEDEE API for global instant Bitcoin payments and you have a winner!
3-min Walkthrough
Head on over to Replit.com and create a free account if you don’t already have one.
Click the USE TEMPLATE button on top right and give your new project a name. Your repl instance will begin to boot up and you’ll see the robust IDE interface from Replit begin to take shape in the page.
We’re basically done, now just need to connect a ZEBEDEE API Key to this new repl instance.
If you don’t yet have a ZEBEDEE account, head on over to the official how-to documentation or the ZEBEDEE Developer Dashboard signup page. Once you’ve got your account setup and verified, create a new Project and fetch its LIVE API Keyfrom the dashboard (important: it HAS to be a LIVE API Key, a SANDBOX API Key will not work). It should look something like this:
Now to place the ZEBEDEE API Key securely in the Replit dashboard, search for the Secrets tool on the sidebar:
Click to NEW SECRET and name it ZEBEDEE_API_KEY and paste the key you copied from the ZEBEDEE Developer Dashboard.
That’s it! You’re all set.
Now press the big green RUN button on the top of the Replit page and you should see a new Webview module pop up with the template’s frontend loaded.
The bottom 4 navigation item links take you to other ZEBEDEE API and ZEBEDEE Developer Dashboard learning resources. You can also find detailed documentation about the @zbd/node Node.js SDK. Lastly, there are guides on how to best deploy this starter kit to services like Vercel and Replit (this guide!).
At the top right of the web app you will find the OPEN PLAYGROUND link. Clicking that will take you to the ZEBEDEE + Next.js Dev Playground page which contains modules for the main use-cases of the ZEBEDEE API — Payments and Payment Requests (Charges), Lightning Address Payouts, Withdrawal QR codes, BTCUSD price ticker and much more.
On the top right you can see the ZBD Project Wallet detailing the balance of Bitcoin (in satoshis) available to this ZEBEDEE API Project key.
Each module is self-contained, which means you can just fill in each of the form elements and hit Submit to watch the magic happen. Results will appear inline.
You can now literally send Bitcoin instantly anywhere in the world! No big deal.
Here’s a Bitcoin Lightning Network payment request QR code I created by filling in the two input fields and hitting 1 button click.
Here I am sending a Bitcoin payment that’s settling instantaneously through the Lightning Network — this time sent to a Lightning Address (e.g. andre@zbd.gg).
The template is meant to serve as both a set of example source code files for developers to learn and get ideas from, as well as a full-blown backend + frontend app development environment. Because it is based on the Next.js framework, developers can get started editing code directly on the template’s JavaScript files and watch their changes reflect live on the accompanying Webview.
We are now at a stage in the adoption of this technology where developers can add support for global instant payins and payouts with mere lines of code.
ZEBDEEE enables every app developer to move money at the speed of the internet, all 1 API away.
Now, Go Build!
The goal with writing this guide and the ZEBEDEE Next.js Template starter kit for Replit is to simplify the process and reduce the steps necessary for app developers to build global instant payments into the fabric of their games, apps, and virtual user experiences.
If you start your repl and it provides a message like the one below, it means you have not properly configured the ZEBEDEE_API_KEY in your Replit project’s Secrets.
ZEBEDEE is the next-generation Fintech built on top of Bitcoin and Lightning Network protocols. Looking to build your next game or app with Bitcoin capabilities?
This is a quickstart guide for those that wish to run a paid Nostr relay. There are now tens of relay implementations out there, but only one with plug-n-play support for Bitcoin Lightning Network payments — Nostream.
This is a technical walkthrough of how to get it all setup!
VM Setup
Choose your preferred VM provider - whether you use Linode, Digital Ocean, AWS, GCP, Azure, etc. For this guide I used the following setup in DigitalOcean:
Ubuntu 22.10, 8GB memory, 160GB NVME SSDs
I recommend at least 8GB of memory given the resource intensive nature of always-on websocket connections. Once your instance is up and running, SSH into that VM and follow the next steps.
# Update deps
sudo apt update
# Install nodejs, npm, nginx, certbot
sudo apt install nodejs npm nginx certbot python3-certbot-nginx
# Setup new `nostream` user (don't run nostream on root)
useradd -m -G docker nostream
# If the group `docker` doesn't exist run groupadd docker
# Set new nostream user password
passwd nostream
# Set bash shell for nostream user
chsh -s /bin/bash nostream
Setup Docker + Install
Commands below will install Docker in your VM.
# Create the keyring folder
sudo mkdir -p /etc/apt/keyrings
# Fetch and add it to folder
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
# Setup proper folder permissions
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# Setup `apt` Docker repository (this is a one-liner)
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Install Docker
sudo apt update && sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
# Check installation is successful by checking verions
docker --version
Setup NGINX
Use the commands below to setup NGINX reverse proxy.
# Delete the default nginx settings file
rm -rf /etc/nginx/sites-available/default
# Paste in new settings file contents (see heading NGINX Settings below)
sudo nano /etc/nginx/sites-available/default
# Restart nginx
sudo service nginx restart
# Map DNS A record to IP of VM machine (see DNS Settings below)
# Request SSL cert from letsencrypt/certbot
sudo certbot --nginx -d subdomain.mydomain.com
NGINX Settings
Use the contents below as the contents of the default NGINX settings file. Do remember to change the subdomain.domain.com to your domain.
When you’re in, you will need to quickly verify your email address (look out for an email from ZEBEDEE with a 6-digit code). Once you’ve verified your email, head on over to the left-hand sidebar and click PROJECTS,then CREATE NEW PROJECT.
Once your project is created, you will be taken to the PROJECT DETAILS view. Each project in the dashboard has a fully-programmable Bitcoin Lightning wallet, and each wallet can be managed using the API Key provided in the API tab, as shown below.
Copy this API Key, you’re going to need it when setting up Nostream.
Bonus: you are also encouraged to place your VM’s IP addresses in the whitelisting field to ensure API calls to ZBD using your API Key are only ever coming from the provided IP addresses.
Now that we’ve gotten the ZBD API Key, let’s place it in the configuration file for Nostream and set it live!
Nostream Setup
Now that your VM is all setup, and you’ve got your ZBD API Key, let’s install and configure Nostream to run a paid relay powered by ZBD.
# Change to nostream user
su - nostream
# Clone `nostream` repo
git clone https://github.com/Cameri/nostream.git
# Open a TMUX session
# (to be able to detach and maintain process running)
tmux
# Start the relay
./scripts/start# You want to start the relay once such that all Docker images are downloaded/built, and the default settings.yaml file is automatically copied over.
# Stop the relay (you will see the NOSTREAM logo once it's running)
Ctrl + C (you can use ./scripts/stop as well)
# Edit the settings file to your liking
# (see Settings.yaml Configuration below)
# Add local.env file to root
touch local.env
# Edit local.env file and add ZEBEDEE_API_KEY and SECRET
# SECRET is a 128bit random hash
nano local.envZEBEDEE_API_KEY="your API key goes here"
SECRET="your SECRET goes here"
# You may need to add a `env_file` property to docker-compose.yml
env_file
- local.env
# Restart Nostream
./scripts/start
# To detach from the TMUX session
Ctrl+B + D
# To re-attach to the TMUX session
tmux a
Settings.yaml Configuration
Go ahead and edit the contents of your Nostream settings file. The file can be found at .nostr/settings.yaml
At first, make sure to change the info properties so they match your taste. This information is public and is provided to any client app that connects to your relay.
Then scroll down to payments properties and enable the ZBD processor and select the admission fee cost you’d like to charge. You can also add any pubkeys to a whitelist if you wish to bypass the charge.
Under paymentsProcessors make sure to change nostream.your-domain.com to your actual Nostr relay domain.
Change limits.event.pubkey.minBalance to the amount you are charging for admission to your relay. (this should not be 0)
Your paid relay configuration is now complete! Go back up to continue with the commands and add your ZEBEDEE_API_KEY to local.env file.
Done!
Once you restart the relay, you should see a console that looks a little bit like this.
The special part is `Payments Provider: zebedee` and `Pay-to-relay = enabled`. You’re all set, let’s test the relay!
Check Relay Connectivity
In order to check that the relay is setup correctly, head on over to WebSocketKing and test the connection to your subdomain.domain.com.
If you’re able to connect to your relay, then it is time to test that the paid access functionality is working. To go through that flow head on over to https://subdomain.domain.com and follow the admission payment flows.
For more details check out the How It All Works section on the The Rise of Paid Nostr Relays sister post below:
If you’re updating from a previous version of Nostream to the latest pay-to-relay version, the commands below are for you:
# Stop nostream relay
./scripts/stop
# Remove old Docker network (you may not need this)
docker network rm nostr-ts-relay
# Stash any local git changes applied to the relay codebase
git stash -u
# Pull latest nostream code
git pull
# Bring back locally stashed git changes
git stash pop
# You may want to change your settings.yaml here# Restart relay
./scripts/start
Security
You also want to make sure to apply a sensible set of firewall port accesses. The bare minimum would be to open ports 80 and 443 for HTTP/HTTPs and WebSockets. Port 22 is default for SSH’ing into a VM. (This config really depends on how YOU set up your Nostream VM).
In Digital Ocean, you can head to Droplet > Networking > Firewall.
Conclusion
That’s it! You’re all setup. This Nostr relay will now only accept fetching and posting of new events by those users that have paid the admission fees.
Now sit back and watch those sweet sweet satoshis stream into your ZEBEDEE wallet as you provide decentralized communications relay infrastructure to the world!
ZEBEDEE is the easiest way to monetize your Nostr relay today!
Use Bitcoin Lightning Network with the ZBD API and start earning revenue for providing distributed infrastructure to the open Nostr network!
Focus on providing the best Nostr relay infrastructure for your users, and let ZBD focus on what we do best — Bitcoin Lightning Network APIs and infrastructure provisioning.
If you’re trying to run a paid Nostream relay, get in touch with me on Twitter @andreneves or DM me on Nostr and I’ll get you onboarded with an invite code.
ZBD provides the industry-leading Bitcoin solutions with the most in depth array of Lightning Network API protocol support ranging from Lightning invoices (BOLT11 payment requests), to LNURLs, to Lightning Addresses, and even Keysend (spontaneous payments). We’re here to support you and your teams on your journey to introduce real value to user experiences!
If you’re building on Bitcoin and Lightning Network, it must be on ZBD.
Unless you’ve been living under a rock for the past few months, you have heard of the up-and-coming revolutionary and possibly-decentralized data protocol called Nostr. Nostr is a generic communications protocol that has a myriad of potential applications, but the current hot topic is social media — aka Twitter replacement. Look no further than Snort, Damus or Amethyst if you want to get going joining Nostr.
If 1 week in BitcoinDev-land feels like 2 years, then 1 week in NostrDev-land is at least a full decade. The sheer number of new client apps, advanced relay implementations, and developers getting their hands dirty with Nostr is simply staggering. The ecosystem is growing so fast that there is already a Nostr Conference schedule for March called Nostrica.
Developer-interest metrics can be notoriously bad at identifying patterns and trends. BUT, if we are to take into account the recent wave of interest into the Nostr protocol simply by looking at the number of GitHub stars on the repository - WOW!
Now you may be thinking that this is probably akin to the growth of other open source protocols that have received similar adoption. And you would be right to think that. But the difference is actually pretty stark when you compare Nostr’s growth with other protocols of similar kinds. Below you see the chart comparisons for Nostr, bitcoin, IPFS, and LND GitHub stars. While it’s clearly really early days for the Nostr protocol, its growth thus far has been nothing short of incredible.
Network Growth
As the Nostr network continues to grow, and software solutions for both clients and relays continue to mature, one of the big discussion topics that comes up time and time again is monetization business models.
Most of the cost of running the Nostr network is on its distributed relay infrastructure. Relays must handle the storage of events, the compute cycles that allow for clients to connect, send, and fetch events, as well as the necessary bandwidth used to relay these events to tens of thousands of users. Currently all of the Nostr relays are being run by enthusiasts — folks that are paying out of their pockets to provide infrastructure for clients to connect and post to.
No one is earning any real return from running Nostr relays in production at the moment, and this must change for the continued growth of the network.
For the network to mature, there must be incentive structures in place that ensure relay operators are incentivized to provide always-online infrastructure to users. Any decently mature distributed network will also have to deal with much more adversarial conditions around spamming and denial-of-service attacks.
While Nostr is itself a lightweight protocol, scaling relays to tens of millions of users will be very costly. Therefore it is imperative that we arrive at monetization schemes for Nostr relay operators to earn returns on their server infrastructure provisioning.
Fee Monetization
While it’s all fun and games to theorize about monetization techniques for Nostr relays, when it comes to actually building these on relay implementations it’s a different beast altogether.
It is important to understand that this is NEW. No one has successfully monetized a Nostr relay, so any and all attempts right now are nothing more than that — attempts. There will be models that work and models that don’t. Ultimately we must start somewhere.
Bitcoin is how Nostr will be monetized.
Bitcoin is the perfect fit for the money layer of the Nostr network. Apart from the obvious reasons around its decentralized nature, censorship-resistant capabilities, and global adoption reach, Bitcoin fits into Nostr because of the Lightning Network. By relying on Lightning Network payment requests we are able to achieve a money layer that provides cheap and instantaneously-settled value transfer.
There are various ways for a relay operator to charge for the work their relay is doing on behalf of its clients. Specifically I believe there are 3 distinct types of fees that operators could begin entertaining in order to make their relays more sustainable from a cost perspective, and more stable from a DDoS and spam-protection perspective.
Storage (pay per size)
The entirety of the Nostr protocol surrounds a generic event object that contains 7 simple parameters. All actions inside of Nostr are events. If you’re making a post to your feed — that’s an event. If you’re editing your profile metadata — that’s an event. If you’re liking a post on your favorite app — that’s an event.
All of these events are sent by clients to relays, and relays have to store that data in order for other clients to fetch it at a later date/time. It then becomes clear that the more events a relay has, the larger their storage needs are. And with the current growth of the network the expectation is that there will only ever be more users, making even more events.
What if relay operators could charge users/clients based on how much data they store on their behalf? Maybe the path forward is to charge X satoshis per every Y MB of event data that is stored on a user’s behalf?
Publication (pay per event)
If we know that everything in Nostr is an event, and that in order to interact with anyone in the network one must publish events, why shouldn’t relay operators simply charge users per event? The proverbial `pay-for-what-you-use` is another model that could be tried by relay operators. The more the user does with this relay, the more it would cost for them.
The biggest challenge for this pay-per-event model to work is FRICTION! Microtransactions are a burden to users if they are not kept out of sight, and interrupt the user experience at every engagement. Users will simply churn out and not return.
I still have a lot of hope that this is a model that will be attempted, but it does feel a bit early for it to work at scale, in an interoperable manner across all client apps and relays.
Admission (pay per pubkey)
KISS = Keep It Simple Stupid
Maybe we should start small, simple, and iterate from there. A straightforward monetization mechanism could be to have a simple allowlist that includes all of the public keys / users that have paid an admission fee set by the relay operator.
The relay operator will then be able to monetize that service with an upfront fee for providing it to users. Additionally, operators are given the ability to further decide to remove users / public keys from the allowlist if they breach any of the Terms of Service they stipulated. Users not in the allowlist will have their relay connections dropped, and no further posting or fetching of events is available for that public key. This mechanism also allows operators to deter spammers, and provides for a more stable Nostr data experience when compared to public free relays.
Nostream is one of the most feature-rich Nostr relay implementations out there. It is written in TypeScript, authored and maintained by Ricardo Arturo - a prolific developer and Core Nostr Contributor. This relay implementation has got support for the most used NIPs, fully configurable rate limiting settings, blocklisting and allowlisting of pubkeys and event keys, and much much more.
On the latest version of Nostream, a relay operator is able to connect a ZBD API key to their relay, and with 2 simple configuration settings activate paid access support.
From that moment on, that relay is effectively monetized through the Lightning Network and payments can be performed by any user from anywhere in the world.
When initiating your Nostream relay, with a simple set of configuration parameters and a ZBD API key, anyone is now able to directly monetize the storage, compute, and bandwidth costs of running a Nostr relay!
How it all works!
When a user visits the homepage of the paid Nostream relay, they are shown the one-time admission fee requirement screen. The user is also provided a detailed Terms of Service that relay operators can choose to modify to their own desires.
The payment orchestration flow is done through Bitcoin Lightning Network, so when a user clicks pay 1000 sats, a Lightning invoice is created and displayed as a QR code. This payment request is payable by any Lightning-enabled Bitcoin wallet in the market.
Once the payment is complete, the user’s public key is then added to that relay’s allowlist. From then on, that user is able to successfully connect to the relay. They can now post and fetch events as much as they want.
Ricardo runs a paid Nostream relay instance at eden.nostr.land if you’d like to try the payment flow yourself.
To make the entire flow even simpler, Ricardo was able to configure each Nostream relay to have its own identity inside of Nostr (public key). Which means that the same information that is shown in the website’s UI is also sent to the user as a private DM message. If their application handles paying directly with a wallet (like Snort does below), the payment flow can be even smoother.
Once the payment settles, the relay also sends a message stating that their public key has been added to the list of admitted users.
Even with just this initial implementation of a paid relay by admission fee, we have already identified a few paths worth exploring further:
Creation of a set of separate NIPs that define events for a relay to send payment requests directly to clients, and have that UI/UX be handled differently than just a DM message.
Creation of subscription services such that relays are able to automatically let users/pubkeys know their access is going to be terminated unless payment is completed within X days.
Given the recent surge of new users to Nostr, one theme has been clear: free relays are melting under the increased demand, while paid relays are providing the most reliable services.
Both nostr.milou.lol and Ricardo’seden.nostr.land are currently running Nostream with paid relays configuration. And more are popping up everyday! If you are seeking a more stable experience for sending and fetching events in Nostr, give a paid relay a try!
ZEBEDEE is the easiest way to monetize your Nostr relay today!
Use Bitcoin Lightning Network with the ZBD API and start earning revenue for providing distributed infrastructure to the open Nostr network!
Focus on providing the best Nostr relay infrastructure for your users, and let ZBD focus on what we do best — Bitcoin Lightning Network APIs and infrastructure provisioning.
If you’re trying to run a paid Nostream relay, get in touch with me on Twitter @andreneves or DM me on Nostr and I’ll get you onboarded with an invite code.
ZBD provides the most in depth array of Lightning Network API protocol support ranging from Lightning invoices (BOLT11 payment requests), to LNURLs, to Lightning Addresses, and even Keysend (spontaneous payments). We’re here to support you and your teams on your journey to introduce real value to user experiences!
If you’re building on Bitcoin and Lightning Network, it must be on ZBD.
Hopefully the next post will be on running a fault-tolerant high-availability Nostr relay. Yes, enterprise nodes are already here!
How app store monopolies are leading to fragmented user experiences and how the rise of money-enabled protocols open the door to novel Web business models
We’ve all seen this story before. An exciting new application that promises to disrupt an industry sector, or introduces some novel technology, and gets everyone hyped-up. Shortly after the team publishes the release to the Apple App Store — lo’ and behold it gets rejected for reason A, item Z, or 3.16.7 rule 25.
This isn’t new. This is actually the norm. The status quo is simply not good enough.
Apple is using its power to force app creators who publish iOS apps on their App Store to pay 15-30% for any in-app purchase, and require those transactions to be processed by Apple’s own payment processing gateways (Apple Pay / IAP). This vendor lock-in is harmful for innovation and leads to exploitative measures.
Thankfully, an alternative exists: The Web! Why should Apple be allowed to take 15-30% of the value created by the team who created the app, who after many failures and thousands of hours of work were finally able to prove product-market fit? Apple is clearly exploiting its monopoly to extract more than their fair share. I'm not saying Apple shouldn't get a share, but it should be significantly lower than 15-30% to be competitive with current market dynamics.
The good news is that Bitcoin Fixes This. The Lightning Network enables bitcoin to be used as money. Bitcoin is interoperable across different applications for small and large payments, with incredibly low payment processing fees (1% or 1 satoshi, fractions of a cent). This is much lower than the traditional finance cost of payment processing, which is 2.9% + 30 cents.
Additionally, legacy systems incur users much larger flat base fees, driving up the minimum amount of funds and the type of fund-flows supported. Bitcoin applications do talk to other bitcoin applications and systems, unlike most USD systems, which provide faux interoperability to customers. Learn more by watching Andre Neves CTO and Co-founder of ZEBEDEE discuss The Future of Payments at a recent talk at MIT.
The ability to support micropayments as low as fractions of a cent allows for transactions that are inclusive of any use case — anyone can afford to transact in this network. Our applications can infuse money into their experiences and make them richer, especially when it comes to e-commerce and social interactions. This lowers the barrier to entry to offer payments in and out of web apps, with transactions that are easy to implement and have no deposit or settlement risk.
In a single night, I was able to build a wallet web application using the ZBD APIs.
I built this ZBD Labs Wallet App to showcase what is possible with Bitcoin and ZBD APIs. The wallet allows users to pay and withdraw funds for real and virtual goods or services, and deposit funds. Here is a live demo of the features. Imagine building your own app experience with monetization opportunities and ways to provide more value to your users.
Any game, application, service, or platform can interact with, and use Bitcoin as its money now. And it is all interoperable with other services, because we all speak Bitcoin.
I hope this inspires folks to add Bitcoin to their experience and make richer UX flows for their users. I hope this inspires folks to look at The Web as the most open medium for building applications.
Think of the new monetization opportunities, the cost-savings on payment processing, and the faster speed to market! All of this can be achieved while supporting many more users and use cases because of lower barriers to entry. That is what Bitcoin offers us on The Web, especially with advanced UX protocols like LNURL.
You don't need to be a Bitcoin expert to add it to your app. The ZBD APIs make it extremely easy to do so, and we have guides and API reference details available on our Documentation Portal.
To close out the year with a bang, we decided to record a new Tidbits episode! Lo and behold the one and only #nostr creator
@fiatjaf and I discuss all things happening in Nostr-land and what's going on since the public funding / support from @jack. This is a laid back conversation and we cover a wide-ranging set of topics, which include:
Main challenges for Nostr adoption
"Stop using Nostr, start building Nostr"
Nostr is an open protocol - can build more than Twitter