-
@ 460c25e6:ef85065c
2025-02-25 15:20:39
If you don't know where your posts are, you might as well just stay in the centralized Twitter. You either take control of your relay lists, or they will control you. Amethyst offers several lists of relays for our users. We are going to go one by one to help clarify what they are and which options are best for each one.
## Public Home/Outbox Relays
Home relays store all YOUR content: all your posts, likes, replies, lists, etc. It's your home. Amethyst will send your posts here first. Your followers will use these relays to get new posts from you. So, if you don't have anything there, **they will not receive your updates**.
Home relays must allow queries from anyone, ideally without the need to authenticate. They can limit writes to paid users without affecting anyone's experience.
This list should have a maximum of 3 relays. More than that will only make your followers waste their mobile data getting your posts. Keep it simple. Out of the 3 relays, I recommend:
- 1 large public, international relay: nos.lol, nostr.mom, relay.damus.io, etc.
- 1 personal relay to store a copy of all your content in a place no one can delete. Go to [relay.tools](https://relay.tools/) and never be censored again.
- 1 really fast relay located in your country: paid options like http://nostr.wine are great
Do not include relays that block users from seeing posts in this list. If you do, no one will see your posts.
## Public Inbox Relays
This relay type receives all replies, comments, likes, and zaps to your posts. If you are not getting notifications or you don't see replies from your friends, it is likely because you don't have the right setup here. If you are getting too much spam in your replies, it's probably because your inbox relays are not protecting you enough. Paid relays can filter inbox spam out.
Inbox relays must allow anyone to write into them. It's the opposite of the outbox relay. They can limit who can download the posts to their paid subscribers without affecting anyone's experience.
This list should have a maximum of 3 relays as well. Again, keep it small. More than that will just make you spend more of your data plan downloading the same notifications from all these different servers. Out of the 3 relays, I recommend:
- 1 large public, international relay: nos.lol, nostr.mom, relay.damus.io, etc.
- 1 personal relay to store a copy of your notifications, invites, cashu tokens and zaps.
- 1 really fast relay located in your country: go to [nostr.watch](https://nostr.watch/relays/find) and find relays in your country
Terrible options include:
- nostr.wine should not be here.
- filter.nostr.wine should not be here.
- inbox.nostr.wine should not be here.
## DM Inbox Relays
These are the relays used to receive DMs and private content. Others will use these relays to send DMs to you. **If you don't have it setup, you will miss DMs**. DM Inbox relays should accept any message from anyone, but only allow you to download them.
Generally speaking, you only need 3 for reliability. One of them should be a personal relay to make sure you have a copy of all your messages. The others can be open if you want push notifications or closed if you want full privacy.
Good options are:
- inbox.nostr.wine and auth.nostr1.com: anyone can send messages and only you can download. Not even our push notification server has access to them to notify you.
- a personal relay to make sure no one can censor you. Advanced settings on personal relays can also store your DMs privately. Talk to your relay operator for more details.
- a public relay if you want DM notifications from our servers.
Make sure to add at least one public relay if you want to see DM notifications.
## Private Home Relays
Private Relays are for things no one should see, like your drafts, lists, app settings, bookmarks etc. Ideally, these relays are either local or require authentication before posting AND downloading each user\'s content. There are no dedicated relays for this category yet, so I would use a local relay like Citrine on Android and a personal relay on relay.tools.
Keep in mind that if you choose a local relay only, a client on the desktop might not be able to see the drafts from clients on mobile and vice versa.
## Search relays:
This is the list of relays to use on Amethyst's search and user tagging with @. **Tagging and searching will not work if there is nothing here.**. This option requires NIP-50 compliance from each relay. Hit the Default button to use all available options on existence today:
- nostr.wine
- relay.nostr.band
- relay.noswhere.com
## Local Relays:
This is your local storage. Everything will load faster if it comes from this relay. You should install Citrine on Android and write ws://localhost:4869 in this option.
## General Relays:
This section contains the default relays used to download content from your follows. Notice how you can activate and deactivate the Home, Messages (old-style DMs), Chat (public chats), and Global options in each.
Keep 5-6 large relays on this list and activate them for as many categories (Home, Messages (old-style DMs), Chat, and Global) as possible.
Amethyst will provide additional recommendations to this list from your follows with information on which of your follows might need the additional relay in your list. Add them if you feel like you are missing their posts or if it is just taking too long to load them.
## My setup
Here's what I use:
1. Go to [relay.tools](https://relay.tools/) and create a relay for yourself.
2. Go to [nostr.wine](https://nostr.wine/) and pay for their subscription.
3. Go to [inbox.nostr.wine](https://inbox.nostr.wine/) and pay for their subscription.
4. Go to [nostr.watch](https://nostr.watch/relays/find) and find a good relay in your country.
5. Download Citrine to your phone.
Then, on your relay lists, put:
Public Home/Outbox Relays:
- nostr.wine
- nos.lol or an in-country relay.
- <your.relay>.nostr1.com
Public Inbox Relays
- nos.lol or an in-country relay
- <your.relay>.nostr1.com
DM Inbox Relays
- inbox.nostr.wine
- <your.relay>.nostr1.com
Private Home Relays
- ws://localhost:4869 (Citrine)
- <your.relay>.nostr1.com (if you want)
Search Relays
- nostr.wine
- relay.nostr.band
- relay.noswhere.com
Local Relays
- ws://localhost:4869 (Citrine)
General Relays
- nos.lol
- relay.damus.io
- relay.primal.net
- nostr.mom
And a few of the recommended relays from Amethyst.
## Final Considerations
Remember, relays can see what your Nostr client is requesting and downloading at all times. They can track what you see and see what you like. They can sell that information to the highest bidder, they can delete your content or content that a sponsor asked them to delete (like a negative review for instance) and they can censor you in any way they see fit. Before using any random free relay out there, make sure you trust its operator and you know its terms of service and privacy policies.
-
@ 57d1a264:69f1fee1
2025-02-25 13:24:49
Galoy released a new product called Lana, a platform for bitcoin loans. The team will provide an introduction and then we'll dive into the design.
To get you up to speed, check out the website, slide deck and podcast interview:
- https://www.galoy.io/lana-bitcoin-loans-platform
- https://docs.google.com/presentation/d/1IQocefpCN5_wKX91EWtLa19IpMS_Ye8goNLAgGQbfdU/edit#slide=id.g31d536107ae_0_0
- https://stephanlivera.com/episode/634/
If you get a chance, please take a peek before the call. That makes the design reviews more useful because we need to spend less time going over the basics.
On `Thu Feb 27th · 15:00 – 16:00 CET`
Join from https://meet.jit.si/bitcoindesign
Check your timezone https://everytimezone.com/s/998e22fc
Track https://github.com/BitcoinDesign/Meta/issues/758
originally posted at https://stacker.news/items/896570
-
@ 57d1a264:69f1fee1
2025-02-25 12:38:46
I've been pondering how LSPs (lightning service providers) might pan out over time and how that might affect fees, and I am wondering what everyone else is thinking. Some people will always prefer to manage their own channels, and for some specific use cases, that might be preferable. But I am thinking about the broad userbase that does not want to do that. We will need a massive LSP infrastructure to onboard people and to enable insane amounts of payments.
LSPs will need to efficiently open and adjust channels for users, using their own liquidity or sourcing liquidity from other providers, using just-in-time channels, batching and/or splicing to reduce costs and wait times. Across all this, along with facilitating payments, they need to make their business model work and offer different options for users to pay for their services.
Users might be able to:
1. Pay-as-you-go (pay X for Y more liquidity for Z amount of time)
2. Pay X per month for Y inbound liquidity
3. Pay X per month for unlimited liquidity
4. Nothing for liquidity, but higher transaction fees
A wallet might also automatically choose an appropriate LSP based on what is the best and most appropriate deal at the time.
Let's look at user scenarios:
- If someone sends and receives the same amount every month, they will never need more liquidity. They just draw down the same channel and fill it up again. So they would only pay the LSP for them assigning that fixed amount of liquidity to them. Maybe options 1 and 2 are good for them.
- If someone receives more than they send (they save a certain amount every month), they will need more and more inbound liquidity over time. They might choose option 2.
- An online store that receives a ton and can't really estimate how much, might go for option 3.
- For option 4, it depends if the higher transaction fees are fixed or percentage-based.
It's a bit like choosing a data plan for your phone (or for internet at home). You can get a prepaid card, a regular plan with certain limits, or go unlimited. And there are separate plans for small and large businesses, etc. And there are massive amounts of complex infrastructure behind these service providers to make it all work.
So when someone starts using a lightning wallet, maybe they have to first pick an LSP and a plan before being able to receive. Or maybe they get a first channel for free and pay higher fees, and are then prompted to choose a plan. Maybe they need to wait an hour until the LSP has enough channel opens for a batch/splice, to reduce costs. A complex market at work.
Is that how things might pan out? Am I completely off? Is it worth mocking up different scenarios?
```
#bitcoin #LN #BTC #Lightning #LSP #service #zaps #sats #wallet
```
originally posted at https://stacker.news/items/896520
-
@ 57d1a264:69f1fee1
2025-02-25 07:28:18
@Voltage team will be building a simple implementation of a Lightning gated API service using a Voltage LND Node and the L402 protocol.
📅 Thursday, February 27th 4:00 PM CDT
📷 Live on Voltage Discord, on X, or on YouTube.
- discord.gg/EN93fDfQ
- https://x.com/voltage_cloud/status/1892938201980919985
- https://www.youtube.com/@voltage_cloud
originally posted at https://stacker.news/items/896373
-
@ 57d1a264:69f1fee1
2025-02-24 04:10:33
As your involvement in open source design increases, you’ll face challenges that go beyond basic UI work. From creating scalable design systems to mentoring new contributors, these advanced areas require strategic thinking, collaboration, and leadership.
This chapter dives into these complexities, helping you handle real-world situations while continuing to grow as a designer.
- Championing Design Initiatives
- Creating and Maintaining Design Systems
- Handling Complex Design Challenges
- Conducting In-Depth User Research
- Balancing Open Source Work with Other Commitments
- Navigating Project Dynamics
-0 Mentoring New Designers
Read more:
https://opendesign.guide/10-advanced-topics
```
#design #nostrdesign #bitcoindesign #ln #grownostr #asknostr #zap #btc #bitcoin #nostr #cashu
```
originally posted at https://stacker.news/items/895377
-
@ 266815e0:6cd408a5
2025-02-18 17:26:16
To all existing nostr developers and new nostr developers, stop using kind 1 events... just stop whatever your doing and switch the kind to `Math.round(Math.random() * 10000)` trust me it will be better
## What are kind 1 events
kind 1 events are defined in [NIP-10](https://github.com/nostr-protocol/nips/blob/master/10.md) as "simple plaintext notes" or in other words social posts.
## Don't trick your users
Most users are joining nostr for the social experience, and secondly to find all the cool "other stuff" apps
They find friends, browse social posts, and reply to them. If a user signs into a new nostr client and it starts asking them to sign kind 1 events with blobs of JSON, they will sign it without thinking too much about it
Then when they return to their comfy social apps they will see that they made 10+ posts with massive amounts of gibberish that they don't remember posting. then they probably will go looking for the delete button and realize there isn't one...
Even if those kind 1 posts don't contain JSON and have a nice fancy human readable syntax. they will still confuse users because they won't remember writing those social posts
## What about "discoverability"
If your goal is to make your "other stuff" app visible to more users, then I would suggest using [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md) and [NIP-89](https://github.com/nostr-protocol/nips/blob/master/89.md)
The first allows users to embed any other event kind into social posts as `nostr:nevent1` or `nostr:naddr1` links, and the second allows social clients to redirect users to an app that knows how to handle that specific kind of event
So instead of saving your apps data into kind 1 events. you can pick any kind you want, then give users a "share on nostr" button that allows them to compose a social post (kind 1) with a `nostr:` link to your special kind of event and by extension you app
## Why its a trap
Once users start using your app it becomes a lot more difficult to migrate to a new event kind or data format.
This sounds obvious, but If your app is built on kind 1 events that means you will be stuck with their limitation forever.
For example, here are some of the limitations of using kind 1
- Querying for your apps data becomes much more difficult. You have to filter through all of a users kind 1 events to find which ones are created by your app
- Discovering your apps data is more difficult for the same reason, you have to sift through all the social posts just to find the ones with you special tag or that contain JSON
- Users get confused. as mentioned above users don't expect their social posts to be used in "other stuff" apps
- Other nostr clients won't understand your data and will show it as a social post with no option for users to learn about your app