Not knowing the content of the video, and assuming there isn't some additional crime that needs to be prosecuted, it's better to let it go. These events are traumatic not just for those who were close to them but anyone who experiences them later.
Through journaling and meditation I've seen how exposing myself to stuff like this causes echoes in the form of random associations, bad dreams, and poorer sleep. I was glued to this when it happened and still think of it often but it has added nothing to my life.
Many people cannot forget, but the rest of us can choose not to create such memories in the first place. 2 hrs? 15 mins? In the cases of terrorism, I recommend zero.
This is the tension with so much social media. Often I find the best thing to do after loading an app or page is go right to the compose window. What comes out? Not always gold, but it's more purely from the broader experience of my life.
nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p Seeing these big problems reminds me of nostrocket's top level problems. Was this kind of thing in your vision?
nostr:note18flj8e4zwv93rm2pmetnzpt0vnv7fk8zcz2fyq5s6ge5lpqrzmnspwwuhx
Let's help one another choose carefully by fleshing these out. Why can't these all be tracked and solved like so many bugs in the matrix? I'm sure many need to be broken down and proven out. Then we invite and fund solutions. I notice the top level problem in nostrocket.org is similarly broad as these listed above.
On July 28th, I submitted my proposal to @HRF for the Serverless Payjoin bounty: Payjoin over Nostr.
You can read the protocol addendum here: https://github.com/Kukks/BTCPayServer.BIP78/blob/nostr/BTCPayServer.BIP78.Nostr/README.md
The proposal is incredibly simple in nature, just as BIP78 was designed to be, to increase adoption chances. All logic within the Payjoin protocol stays the same, so the version is still 1. It is asynchronous (receiver can process later when back online), encrypted (communication is end-to-end encrypted), and lightweight (no server requirement, leverages existing Nostr network).
In addition to this, I also added building blocks for a new experimental addition: Nostr Payjoin Market.
If your wallet supports receiving Payjoin, you can share a static payjoin endpoint using the Nostr Coinjoin Discovery protocol (https://github.com/nostr-protocol/nips/pull/384). Other wallets, which support Payjoin but want to send money to wallets that don't, can use these static endpoints to enhance their transactions. The goal? Make every transaction to every wallet a coinjoin.
See the sample wallet code and additional detailed description: https://github.com/Kukks/BTCPayServer.BIP78/tree/nostr/BIP78SampleWallet
See quick video demo of prototype:
nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr Was looking to log an issue but didn't see one in Help so hope you don't mind the at. The URL-matching in Primal causes an error on this situation ending with a ) . Example from above is https://github.com/nostr-protocol/nips/pull/384)
The main effect I see Bitcoin having right now is making the elites think twice about infinite money printing. The authorities are just now coming to grips with how hard it is to identify and track Bitcoin holdings and usage. If this causes even 1% less money to be printed a lot of suffering will be avoided. While advances in privacy and other aspects seem to be happening quickly this involves big cultural shifts and I suspect will take decades to play out. Stay humble, stack sats and never KYC.
This is an insidious fight you stage.
Here's another one that I had created.
note1e9eu6jchsmjd0vpk9wglqkslvzkygjcy5z07k5vnxde2ucdxqerqzguaxv
Just now I created (in duplicate) one about the problem view opening up at the bottom. I didn't get any feedback that my submit button worked so that's why I pressed it twice. Ahh, and I see now that it didn't make it into the context tree so I'll hold off until I can learn more about what's missing there.
Problem: When there are many comments, the problem view opens with the view at the bottom
When clicking "read more..." on an individual problem with many comments, the view opens scrolled-down. This assumes the user is mainly interested in the comments, however it seems best to open at the top so the problem description can be read first. Same behavior seen in Chrome and Firefox.
#### Solution: Start with the view at the top of the page.
I created a PR for this.
I'm not sure how Spaceman deals with the various relays, but when I first got going 36+ hours ago and paid for the 688 relay I think there was some lag before my events were accepted. Maybe whatever I tried first was pushed through my other relays but didn't get into the 688 one. Is 688 the source of truth for Spaceman? I'm still getting messages from some relay called Layer.systems and I don't know if that's related to 688.
I think he's asking if it needs more memory, or if this was just time spent optimizing the code, or limited query conditions. That kind of thing.
I don't think you can ruin a protocol with usage. You can only create more evidence of problems to be solved. A strong social network will make impostors easy to spot because nobody knows them. If Jeff Bezos really joined he'd be connected to some set of other Amazon peeps and somebody I trust would know some of them. It's that six degrees thing. It only fails if people ignore this connection-based vouch with prejudice.
I got this running which was very simple, so that's awesome. Also created a sub-problem about comment ordering and a PR to solve it. I have another quick change of the color for comments from this dark-greenish to a little lighter blue and I wonder if I should just PR it or create a sub-problem for that. I guess it'd be good to discuss more problems before implementing solutions but I'm trying to understand how formal the process should be as of yet.
I'm claiming [Problem: Comments are in newest-first order] on the nostrocket problem tracker so that I can work on it and other people don't duplicate my efforts.
Problem: Comments are in newest-first order
Comments are currently in newest-first order, which may be good if you're familiar with the situation and want to just see what's new. I believe most viewers will be seeing for the first time and attempting to read the history in chronological order.
#### Solution: A PR is forthcoming to make the order chronological.
I fully agree. I say this as a non-UX specialist who got by pretty well with the copycat approach.
Here there's obviously a lot of room for experimentation and with guidance from UX specialists like nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac. I guess one way to support novel UX is to help fund research that demonstrates first-principles-based improvements.
Nostrocket excites me because even mindless, copycat UX can be posed as a problem, debated, funded, with progress along the way.
The way I look at UX is basically to copy the most popular things in use or that I use. A lot of research has been done and money is on the line for something like GitHub. I get the reimplementation here to integrate with merits and rockets but would probably just nudge toward the familiar. Filtering sounds good especially if it can persist past the # in the URL.
Awesome! I didn't have a github account for this nym so just set one up. In the next few days hopefully I can get this running locally and start tackling problems. I'm especially interested in that problem tracker clunkiness one.
I'm requesting to join the Nostrocket Identity Tree and claiming my permanym: OriginalSize
Problem: Comments on problems don't show attribution
I commented on "Problem: the Nostrocket problem tracker is clunky and annoying to use" and while I can see my comment, nobody else knows it was authored by me. At least I'm not seeing the attribution from Spaceman. This means bad behavior may persist longer than it would if attribution were clear. It also makes it hard to carry on a conversation using the usual @user convention that people are used to.