2024-05-18 23:13:28
by npub1xts…kk5s
Pairing a nostr query with a nostrscript(wasm) filter makes a lot of sense: the nostrscript can be jit-compiled and cached, and the query plan is determined from the base nostr query so that the results can start returning instantly and efficiently. I think I just came up with a new kind of database powered by nostr 🤔
Arbitrary but fast sandboxed code execution to query a database sounds really cool, and it can be really fast, fast as strfry.
What if instead of just filtering, we pass a reducer, so you could effectively do map-reduce over nostr data 🤔 this can be used for counting and grouping nostr notes in arbitrary ways, directly from a query, efficiently. Holy shit.
2024-05-18 18:58:15
- reply
by npub180c…h6w6
You clearly don't know what you're talking about since everybody knows Mastodon has a much better UX than Nostr.
Also PGP has a better UX than Nostr, using Linux has a better UX than Nostr, running a Lightning node has a better UX than Nostr, running your own email server has better UX than Nostr, having popcorn stuck in between your teeth has a better UX than Nostr, getting punched in the face has a better UX than Nostr.
2024-05-18 02:25:16
- reply
by npub1qjt…z44v
You just have to compile the gpg binaries, add them to your user shell, generate a new public/private keypair on a Yubikey, set an admin PIN, set a user PIN, backup the admin PIN, backup the user PIN, backup the gpg private key (securely that is), reconfigure your ssh connectivity to the gpg-agent, update your local terminal config and paths, source that config, enter the decryption commands, enter your user PIN, and then tap your Yubikey. As simple as that! 😂
2024-05-17 20:12:48
by npub1xts…kk5s
the most eye opening think I’ve ever experienced design-wise was adding a new note pop-up feature that always popped up at the top of your timeline when you were scrolling, that showed when new notes have arrived.
It did this on every new note in realtime. It would keep popping up over and over, this was so stressful and jarring that it made me realize I have a huge amount of power to cause stress just from small design decisions.
This made me think: there is a large landscape of possible design decisions that can greatly increase or decrease user stress.
One example in damus is that I just show a dot on the home button, but I don’t show the number of new notes. Some people will consider this less helpful, but it’s damus’ way of saying: just chill, there are new notes, don’t worry about how many.
Saving the scroll position is another subtle design choice: it enables a way for people to scroll up to see every note they missed since last session. Is this necessarily a good thing? To me this is stressful, it’s like obsessively making sure I don’t miss any note.
We will still likely add this feature, at least to notedeck/android, but it does have some stress-level difference in the way the app is used.
Something to think about. Thanks for coming to my ted talk.
2024-05-16 17:15:01
- reply
by npub180c…h6w6
> As opposed to just making a fresh 2 keys?
Yes.
> try do just combine signatures naively without the protections of musig2 against adversarial behaviour?
I see, that makes sense.
> Very unlikely to make sense
I think the use case is something like:
1. I have been using this raw private key in my desktop and so far it hasn't leaked, but I am afraid it will eventually leak.
2. So I split it in 2 and put one shard in a hardware wallet and the other I leave on the desktop, delete the raw key.
3. Now to sign events I need the combination of the two devices, communicating somehow to produce a signature.
(As I write this I realize it's not a very good use case, so maybe this discussion is a waste of time.)
What could go wrong? If one of the two shards is leaked to an attacker, could him find out about the other shard somehow?
Or, a more generic question: since the two shards are pre-defined by myself, are they immune to the key subtraction attack since that would require the attacker to use an entirely new key?
2024-05-16 09:09:58
- reply
by npub1gcx…nj5z
Yep, our push server knows which keys are in which device ids if you activated Push Notifications. But that into is not public, only the push server sees it. Device IDs are random numbers, so they don't expose any other info about you.
But if you are concerned about that, you should know that if you use multiple keys in the same device, relays and image servers, including proxies, can also see which keys are together by just logging where requests are coming from. They can do that roughly well even through Tor.
VPNs can muddle this info, but the VPN server itself will also know that info (and much more).
Happy to code schemes that obfuscate that info, but to the best of my knowledge, Signal, SimpleX servers also know the same info based on Device IDs/IP info.
2024-05-16 08:02:12
by npub16jd…33sv
The true purpose of "AI" is not to advance humanity, so much as it will be to no longer hold those accountable who were once liable to be held accountable.
"That was the AI's fault," we'll be told.
As we saw with Google's Gemini, despite the model only being able to generate end results by the data and rules it was given.
As we saw with Israel's Lavender program, which likely and knowingly killed innocent civilians only under the suspicion of ties to Hamas terrorists.
As we will see it again, I'm sure, used as the scapegoat for some avoidable egregious wrongdoing. Granting the powers that be unjust immunity from actions claimed not to be their own, no matter how clear it might have been by design.
2024-05-15 23:34:23
- reply
by npub180c…h6w6
You mean you already have a pubkey, but you want to split it into multiple and then sign cooperatively? I think you can do it, yes. But the assumption will be that you will control all the shards and not give them to others, and then you don't have to use MuSig, you can do a simpler, more naïve protocol.
But I'm just guessing, we should ask someone who actually understands cryptography. @npub1vad…nuu7, maybe?
2024-05-15 01:50:46
- reply
by npub16jd…33sv
While I have mixed feelings about Tor, I think it certainly is a better choice than any wholly centralized VPN for-profit business you pay for mental assurance with good faith "trust me bro, we aren't logging" marketing.
Then of course, there's also I2P as well as some other honorable mentions of onion-routing networks such as safing.io SPN or Lokinet.
But this all depends on your threat model. If you're simply wanting to stream video from a country you aren't supposed to, then a basic VPN is fine. If you're an activist who's being pursued by a nation-state, then an onion-routing network may help prevent being deanonymized.
Who/what you use just depends on the purpose and nature of the intended outcome.
2024-05-15 01:40:11
- reply
by npub16jd…33sv
It would certainly take a major coordinated effort for all of the countries to fall in line in order to shutdown the directory servers, no question.
The likelihood of it ever happening? It's certainly plausible, but I'm still mixed on if realistically feasible. Though, that's exactly the point of my earlier note. The fact that it is even possible, should be alarming. And as you bring up, the West is now increasingly becoming anti-free-speech, often targeting activists. Which I acknowledge the correctness in @npub16r0…z5pl saying in most cases those arrested were due to bad OpSec. That's absolutely true.
However, as far as I know, the likes of fiatjaf couldn't one day decide which Nostr relays/nodes he likes/dislikes and effectively shut down any of them by having some centralized directory servers signal to "nostr browser" that they should no longer use those relays/nodes, unlike what the Tor Project can do.
So, there is an element of centralization that folks should be more aware of with Tor. What they do with this information is up to them. At no point have I said people should stop using Tor, simply by knowing said information.
2024-05-14 21:10:21
by npub1xts…kk5s
Nostrdb data is super easy to export. It’s just a single file. Can back that up to the cloud, or more interestingly, sync it to other nostrdb nodes. What if your phone synced to your desktop machine over the local network? All of your notes, nostr contacts, DMs, drafts could sync between your devices without global network connectivity.
Nostrdb has command-line tools[1] for exporting and querying the data locally, It is the same format that Damus iOS uses, so you can take your DB and use it on desktop or android.
[1] https://github.com/damus-io/nostrdb?tab=readme-ov-file#cli #note13dn…vggp
2024-05-14 17:11:28
by npub1tv8…7wn2
Whew... I've been quiet the last few weeks because I've been BUSY with my other passion project: coaching -- and helping to RUN -- high school boys gymnastics.
Y'all out on social media don't have much visibility into this side of my life. High school gymnastics MADE ME WHO I AM. I love being a coach now and trying to offer a similar experience to a new generation of kids. And this year demanded more of me than ever.
Please read on to understand why I'm so fucking proud of what my small gymnastics community accomplished.
---
Last year the state dropped Boys Gymnastics as a high school Varsity sport. So coaches across the state took it upon ourselves to start our own league. I was part of the 9-member Steering Committee that made this season happen.
We spent MONTHS working out our own process for training and certifying our judges, organizing Sectional meets, and running our own STATE MEET.
AND WE SUCCEEDED!!! We ran a full season that concluded this past Saturday with 142 gymnasts from 33 different schools competing in our State Meet!
https://i.nostr.build/KGgz2.jpg
The meet ran smoothly, the gym was packed (by our standards; this isn't TX football...), and the kids had the high energy, high stakes State Meet they deserved.
https://i.nostr.build/kZqWm.jpg
I volunteered to create and run the scoring for the meet. Had to write 5000+ lines of code, work out all the coordination logistics, do all the ENDLESS data dumps and filtering along the way to figure out who qualified and how to slot them into the meet, train the workers, brief all the coaches and judges, and -- most importantly -- oversee and troubleshoot the entire process during the meet.
https://i.nostr.build/5GD7v.jpg
It was STRESSFUL. My code drove our leaderboard displays as well as provided live web-based results. I'd take quick glances up at the display board and pray it wouldn't be showing an http 404 or 500 error.
https://i.nostr.build/7GDRV.jpg
(pic doesn't do it justice; the leaderboards looked AMAZING!)
The State Meet was in my hands, on my shoulders. If I fucked up, the meet would be a disaster. Thankfully there were NO problems. Coaches were AMAZED at how well everything ran.
We had to figure out EVERY aspect of this meet. Managing who qualifies, who pays for what, selecting officials, how does the host school break even or possibly profit, all the day-of logistics, designing and ordering the trophies and medals, even produce the freakin' meet decorations, signage, and souvenir program!
https://i.nostr.build/DjQlJ.jpg
ENORMOUS amount of work. But at the end of the day, we ran a PHENOMENAL, professional State Meet.
https://i.nostr.build/dwZd4.jpg
https://i.nostr.build/eZqOm.jpg
In many ways it was even better than previous years, because the coaches collectively got to make the calls and run it how WE wanted.
ps - all these photos are courtesy of coach Abi Diaz who shot the meet with my camera. We ended up with ~850 RAW images I then had to cull through and process. Yet another monster task!
---
In addition to all that, I had OTHER responsibilities in the closing weeks of the season.
COACHING:
Our team fought and scraped our way to earn a TOP TEN berth to the State Meet! We also had 11 individual event qualifiers, the most of any school in the state. I strategize and optimize our routines for our rulebook and I'm the technician in the gym who refines the most subtle / difficult aspects of our key skills. Unfortunately I couldn't be with our team during the meet since I was so busy running the scoring.
https://i.nostr.build/M5wna.jpg
JUDGING:
I judged 2 of the 4 Sectionals meets (head high bar judge!) which determine who qualifies to State. Plus a ton of dual meets throughout the season, Varsity invites, and culminating Varsity Conference meets. I'm usually voted by the coaches to be one of the top 12 judges in the state and therefore asked to judge the State Meet, but obviously had to decline this year in order to focus on my other duties.
---
ONGOING:
I'm on our Rules Committee which is just starting to gear up to review and revise our rules for next season. And volunteered to remain on the Steering Committee to do it all again in 2025.
2024-05-14 09:42:52
by npub1226…grkj
For a viable encryption scheme for Nostr we need:
1. plausible deniability: it is not possible to prove a message was sent by someone
2. sender privacy: the sender must not be known to anyone including relays
3. recipient privacy: the recipient must not be known to anyone including relays
4. DoS resistant: clients should be able to tolerate an attacker creating as many events as they want in an attempt to disrupt communication
5. relay filtering compatible: relays must be able to implement measures to filter event floods to some extent to assist with 4.
6. restricted-write relay compatible: the scheme must allow a way for relays with a restricted writer set to be able to be used as an outbox or inbox
7. post-compromise security: the protocol must be able to recover in a reasonable amount of time from a total leak of client state assuming the master private key is not (signer/extension)
8. forward secrecy: the protocol must not leak any messages before compromise if one of the master private keys, or both, are compromised
Gift wraps fail 1, 3, 4, 5, and 8. 7 is not applicable
The proposed DR scheme fails 1, 3, 4 and 5.
My proposed scheme passes all of them, but 7 still needs to be fully validated.
2024-05-13 05:39:28
- reply
by npub16jd…33sv
Nah, not that either. You're still missing my point. If a contact (friend, family, etc) outside of Signal has your phone number saved with your real name, and you use that same phone number for your Signal account, and your friend/family use a service that uploads their contact data with your real name/number in it, then they have effectively doxxed you as the owner of the Signal account to three-letter agencies.
2024-05-12 04:09:25
by npub1xts…kk5s
trees can be scary to programmers: lots of pointers flying around everywhere to different parts of memory, lots of memory allocations, but fixed and balanced trees have a very simple representation that you can store and navigate in a straight line (programmers like straight lines, we call them arrays)
The numbers in this image are the index into an array. Given any position in the tree, you can find a parent or sibling element with a few arithmetic operations which result in another index.
No allocating complex data structures, no chasing pointers around, just a bit of math to jump around a tree flattened into a straight line. As a programmer finding elegant solutions like this is a pure dopamine hit. Code can be beautiful 🥹
#nerdstr #treestr https://i.nostr.build/O49QP.jpg
2024-05-11 02:27:48
- reply
by npub16jd…33sv
You're in luck, Cloudflare has a large presence in Africa with the following data centers:
Accra, GH*
Algiers, DZ
Antananarivo, MG
Cape Town, ZA*
Casablanca, MA
Dakar, SN
Dar Es Salaam, TZ
Djibouti, DJ
Durban, ZA*
Gaborone, BW
Harare, ZW
Johannesburg, ZA*
Kigali, RW
Lagos, NG*
Luanda, AO
Maputo, MZ
Mombasa, KE
Monrovia, LR
Nairobi, KE*
Port Louis, MU
Reunion, FR
Tunis, TN
*AI inference locations
2024-05-10 14:05:10
- reply
by npub1gcx…nj5z
What bothers you about it?
For instance, some people don't want the encrypted events being sent to a relay, so we are coding a relay setting for a local database of drafts (and other settings). In that way, you can use something like Citrine to store your drafts and avoid putting them out in your regular relays.
So many people have lost what they were typing on Amethyst that Drafts became our solution to make sure that never happens again, even if the app has a bug and crashes, the Draft will be saved.
2024-05-10 04:48:01
by npub16jd…33sv
#Signal is a honeypot. Change my mind.
Most people aren't using a burner. You might use an alias on Signal, but if an irl contact has your number saved and they've ever used Facebook, Snapchat, or any other service that uploads the phone's contact list to their servers, chances are the 3-letter agencies know who you really are. Therefore, revealing your true name, as it's unlikely your irl contact will have saved you as an alias unbeknownst to them. Effectively, your normie friends inadvertently rat you out.
2024-05-10 03:48:32
- reply
by npub16jd…33sv
No fucking around with config'ing a VPS or webserver like nginx/caddy/apache, or dealing with a taxing memory system bound by finite resources, or worry about getting DDoS'd, or if you'll run out of disk space, or... anything really. #Nosflare is just better. You don't even need to bundle like the repo readme says... you could literally copy/pasta the example.js and dump it into your worker and edit the relayInfo deets, set the env vars and R2 bucket, and you've got a working relay in 5-10min. It's prob one of the easiest and performant relay implementations available. https://image.nostr.build/746412ea368b2f062028d54e2743bc812e637939bef4d5f903262e94bbee55f5.png
2024-05-09 23:50:25
by npub1xts…kk5s
Spent all day improving nip10 robustness in damus. We now do nip10 marker replies, so damus replies should always be correct in every client.
I also integrated nostrdb into thread construction, so damus should always be able to reconstruct a thread even if the root thread marker is missing or wrong (many such cases). This had the largest impact, i very rarely see thread loading issues.
I am pushing out TestFlight today for purple users to test, we plan on submitting this tomorrow on AppStore with many more improvements, will drop a video once its live.
Threads have been a pita in damus but this should improve things a ton. Thanks for your patience 🙏
2024-05-09 05:29:09
by npub16jd…33sv
The beauty of a serverless approach to #Nostr relay is it's not entirely bound by the common resource or security constraints of a modern VPS. Since every REQ is querying static event json that's cached at the Cloudflare edge, you won't have client subscriptions chewing threw memory like you would normally with a postgres or sqlite. The only current drawback is that events aren't currently streamed, but sent in chunks of 25. Though, I plan to support real-time soon.
Furthermore, the security of #Nosflare far outweighs a VPS that you would have to harden, either due to some installed dependency, weak firewall, or insecure SSH, the onus is on you. Whereas, there's not much an attacker could compromise with the Cloudflare worker as there's far less available entry points. Overall, it's just better in every way; performance, security, scalability, and cost to operate.
#nevent1q…27nm