Last Notes
"on Nostr or Primal"
Primal is just a client, and even that is debatable. Nostr is the protocol that clients and relays use to "speak the same language" with one another so that things are interoperable between most clients that do the same thing. Primal has no "groups" feature that I am aware of, where people in the group only see messages from one another, and no one who hasn't joined the group will see the messages. There are ways of making groups outlined in the Nostr protocol's improvement possibilities (NIPs), but it is not expected that every client, or even most clients, will support everything that can be done with the Nostr protocol. You are likely going to need to find a client that has the feature you are looking for, but we really need to define what it is you want before I can recommend a particular client to you. We'll get to that in a moment.
"the chaos of the main feed"
The main feed is only chaotic if you are looking at a global feed (max chaos), a relay feed (variant chaos based on which relay), or some other feed that puts posts in front of you from people you haven't actively followed. If you only follow certain people, and your main feed only shows you posts from the people you have actually followed, then it won't be chaotic at all. Primal in particular errs on the side of putting content in front of new users when they haven't had the chance to decide who they want to follow, so that they don't end up with an empty main feed when they first join. That means Primal may not be the ideal client for your plan to onboard people to a feed with no content except other people they personally know from an existing social circle.
Now comes the question of what you actually want. Are you looking to have a group chat, similar to Telegram or Discord, where everyone is talking to each other and seeing all the back and forth in a single feed? Or are you wanting something more like a micro-blogging feed, where someone makes a post about some topic and others can reply to it, but the replies are only seen by others when they click on the original post? So, similar to Primal's main feed, but only showing posts from people within your social circle.
If you are looking for the chat-group style, then you want to find a Nostr client that supports Relay Based Groups, like Flotilla, Cha Chi Chat, or Wisp, or one that supports encrypted group messaging, like White Noise.
If you are looking for a micro-blogging style of interaction with only people within a specific social circle, there are a few ways to achieve this:
One would be by using a hashtag for your group, and having everyone in the group use that hashtag on all their posts, and follow that hashtag rather than individual users. This has some obvious drawbacks, as you already observed. First, it requires everyone to remember to include the hashtag in their posts, or else it just won't show up in everyone's feed. It also runs the risk of the hashtag being hijacked by spammers. Additionally, others outside of the group will be able to see the posts made by people within the group, assuming everyone is posting to publicly readable Nostr relays. This may or may not be a downside, depending on whether you want your group's posts to be visible to others. However, it does have a major benefit, as well: You can control which of your posts are intended for that specific group to see and which ones are not based on whether you include the hashtag. When others in the group have gotten used to Nostr and are wanting to interact outside of the group, they can also start branching out to use other feeds and make posts with other hashtags or no hashtags at all.
The extreme left-curve method would be to use a client that doesn't show any posts from anyone you haven't actively followed, then have everyone in your group follow one another and ONLY one another. Then their main feed will not be chaotic at all, but will instead only show them posts from people within your social circle until they are ready to venture out from there. I am pretty sure Amethyst still operates this way, so that may be a good client to use with this method. The downside is, you have to ensure that everyone manually follows everyone else, or you can speed up the process by creating a follow pack for them to just follow everyone listed on it at once, but then they will have to manually update their follows when someone new is added to the follow pack. Also, even though everyone in the group is only following one another, their posts will still be visible by everyone else, assuming you are all writing to public relays. The upside is, this method should work with most Nostr clients, so you don't have to be as picky about which client you use. The only one to stay away from would be Primal, since it actively tries to get content in front of new users by requiring them to follow at least one of their default lists of users at the time of onboarding.
Another option is setting up a follow pack and having everyone in your group use that follow pack as their main feed. You then would control who is included in that follow pack as you onboard more people from the group. There are tradeoffs with this option as well. Not all clients allow you to use follow-packs as a main feed option. The two best ones I found are Primal and Ditto. However, Primal did not show very many of the available follow-packs, so you would be relying on them to surface your follow-pack as an option for your group to add as a feed. Additionally, you would not have control over which posts show up in the follow pack feed, and which ones don't. For instance, I am included in the "Following Jesus" follow pack, and anyone who uses that follow pack as a feed will see all of my public posts, whether they are about faith or not. Like the hashtag option, using a follow pack for your group also does not keep others from outside the group from seeing your posts that are intended for your group, assuming you are all posting to publicly readable relays. The benefit of this option is that no one has to remember to include a hashtag in each of their posts, and you can add new members and remove old members by simply updating the follow pack.
A similar option is using a list, rather than a follow pack. Lists are designed to be used by the person who made them, though, so there is only one client I know of that allows you to create a feed using a list created by another user: Coracle. Even then, you can only use lists created by users within your existing social network, so everyone from the group you want to onboard would have to follow you first, and then they would be able to create a feed in Coracle that uses a list of users you maintain. This method has all of the same upsides and downsides as the follow pack option above, but with the added complication that it only works with Coracle, since other clients will only let you create a feed using your own list.
The last option is running a private relay for just your group, and one that allows you to whitelist who can read from and write to it. Most relays out there will allow anyone to read from them, even if they restrict who can write to them, so you may have a challenge of finding exactly what relay implementation you want to run. You also will need to know a thing or two about how to run a relay and safely expose its endpoint so others can connect to it, unless you use a hosted relay through something like relay.tools, but I am not sure if @nprofile…nkgf 's relays can restrict who can read from them in addition to restricting who can write to them, and there is a monthly cost associated with having a hosted relay. The downside to this option is, you will need to make sure each member of the group sets this private relay up as both a read and write relay, and if they don't want their posts to be public, they will need it to be their ONLY relay. If they want to have all of their posts public as well, then they can have other relays. If they want to have some of their posts public and others only visible to the group, they will need to use a Nostr client that allows them to specify which relay(s) they are posting to on a per-post basis. Something like Jumble.social or Coracle.social. They will also need to set up that specific relay as its own feed, which is also possible in Jumble and Coracle. The upside of this method is that you can restrict who can read from and write to the group's relay, and each member of the group doesn't have to manually follow or unfollow when new members join or old ones leave. When members of the group want to explore Nostr more on their own, they still have the option to add more relays and follow other users, too.
So, as you can see, Nostr has a lot of flexibility for doing what you want, and you have to choose the option that best fits with your particular use-case, since each option has its own tradeoffs.
woah, they're getting ready to fly!! emptynestoor soon 🐧
This is true. Latest Steam is down bad, almost no fighting 😭
😂😂😂☢️
https://image.nostr.build/21e5f374ce06bcb7d9c586633160491e7bf82d845eb1f30d5f795939c9b9dbf8.png
I see this on every Nostr app actually, including simple stuff I make myself. Yakihonne has a similar feature that shows where notes were sent successfully. Almost never do all relays respond, it's just how it is. And yes, a failure might have actually worked, which makes it all the more fun 🤣
Personally I get the best end result with Amy, so I keep using it.
oh, yah its been down for me for a week or so.. i just assumed people were stupid.😂 tbf, i do this with most links.. different era.
hardest part bout developing nostr apps is i gotta read all the insane shit y'all be producing.
if it werent for @Noshole 's humming birds.. we'd be cooked. 😅🐳
do you use load images in RT or do you keep that off? any other slow internet tips i can improve? new features are going to be selective modes for spidering out for replies-to (such as outbox, relay hints, cache relay or none)
I'm cooking up a sweet update for RT android, just have to get gradle to calm down so i can release it.. 😅
I am still trying to figure out how to get only good outbox relays out of nip66 records that will accept posts from the user or good inbox relays, etc.
I fixed it with uBlock and my fucking firewall.
inbox with WOA fixes this 😂
The differentiation for public+small versus private+big makes sense to me, as it's like the difference between throwing some coins into a donation basket and transferring $500 to cover rent.
Money transfers are more privacy-sensitive when they are larger. I think we all naturally sense that.
It's already easy to fake zaps. Just have two npubs zapping each other. I do it for testing, between @npub1l5s…gx9z and @npub1m4n…c2jl all the time.
Public zap receipts for non-trivial amounts are overrated. I do think that small-ish public zaps are a strong signal and give people a chance to advertise without pissing everyone off, as they send the ad along with some cash.
decouple the events. have it send a nip17 giftwrap dm "sent you a payment". if the payments are faked, or valid, allow the client to publish attestations for the sender/receiver npub like a commerce rating.
We would just need someone with a large npub to kick off a working group thread by publishing a kind 30817 (you can do that from my client) event with a title like "Silent Payment Bitcoin Zaps" and a short text explaining what the goal is. The actual spec could be derived from the discussion or added in a fork and then merged back in.
It would be the first Nostr Core spec written and developed on Nostr, @npub180c…h6w6
@npub1gzu…a5ds @npub1xts…kk5s @npub10np…tl5h @npub1qdj…fqm7 @npub1der…xzpc @npub1226…grkj @npub1gnw…errq @npub1wqf…qsyn @npub1syj…f6wl
I'm actually kind of, sort of, low-key interested in on-chain _private_ zaps that don't suck and don't look like a government surveillance wet dream. Especially if clients were clever about it and used addresses from kind 10133 payment target events or w-tags on profiles (so, opt-in!) and recommended Lightning vs on-chain, depending upon the amount sent?
Do we have a working group for that, to come up with a NIP for it, so that client devs like me can implement them? I don't know, if the tech is there, yet, but we could at least get a band together or something.
Do any of you know of anyone working on this, that I didn't tag? Or does anyone want to just reply here and suggest themselves? 🙋🏻♂️
@npub1gcx…nj5z would you be interested in offering that as an alternative for your users, or even maybe as the default, if we got it to work?
Don’t listen to this man he’s obviously never owned an ultra sonic cleaner
the carb is never 'clean' 😂
What about sending BTC through a blender/mixer?
?
Users can interact with bitcoin in many different ways
Users can I have a hot wallet
Users can have a cold wallet
Users have a lightning wallet
They don’t have to be connected
Bitcoin as Chuck E. Cheese token?
I disagree this was the intention of zaps, but that is what they were implemented as. Then much later I realized that and was disappointed. It's ok, but saying this is what everyone wanted, I don't believe that.. JB almost immediately tried to fix it with private zaps but those aren't private either. The idea went wild for a bit with everyone pumping it, and now we are here. (A place where we only send dust because it's too public).
Also, just the mentality:
1. Build a major feature that is a ticking time bomb.
2. Tell people to not use it in a normal fashion because it's actually pretty horrible.
If they send it to a hot wallet, then that wallet is potentially tainted. If they send it to Lightning, then why not just send it to Lightning, to begin with?
The wrench attack is an attempt to get them to transfer that $50 to a wallet with some serious money in it, so that they dox their main wallet.
We stand with President Vitor!
https://npub1etqwgv34spk6p98s0pa9kp8zntgyevdrcl49eas7mswr8pe5pq4sfj8ues.blossom.band/168c141188f94398426ea262a0fed7943697a0ac3305d48fa43ab415e996dd18.jpg
one got stuck in the gargage, we caught it and released. it was chirpin ALot.. poor thing.
I think most users would have fought for public zaps anyway, even if they weren't an option. Zaps aren't money, they're a social signal.
agent already trained in nak so can use above maybe
user older DDR3 DDR4 gen build one less $1000 - not topnotch but can moderate workload
doxxathon?
https://media.tenor.com/NyF0cA41lWIAAAAC/dog-doggo.gif
GM
https://image.nostr.build/9cbd5119109a2f5b1b18ab2615229635ecc4aecce51ea30dc83c95e7e91ea08c.gif
i silently celebrated this like it was already a done deal. sounds excellent. my apologies 😅✅✅✅
so, it sounds like we just need a request to zap protocol, that's a lot like an LN address, and it gives you a different btc address each time cc @npub1xts…kk5s
we really gon let the bitcoin coat-tailers muddle these waters? hehe. maybe. sure. for now.
all it means is that you may have to scan 1m addresses when restoring from backup
thats it
yes i assumed btc pay did it, so yeah, but this thing you mentiond where none received thats what worries me
Zaps are hoooot
https://i.nostr.build/5m9h6uTzGYFjxGY9.jpg
how do you think BTCPayServer and every system that does onchain receiving works?
(It’s fine)
I recommend using BIP-32 to derive subkeys.
One thing to be aware of is gap limit. If you have 1K addresses that got issued, but none of them received, some wallets will just give up on scanning by when they see 20 addresses without any action
So, back up the index of the last address issued somewhere, just to make your life easier
betta sit up 🌝⚡ we talkin zaps neah!