#[1] just FYI your metadata now only has 'lud06' and nothing else. Maybe that is intended, but I think I'll need to implement petnames so I can more easily recognize Melvin Carvalho
I say NO-STIR like "vodka, shaken, nostr". I'm trying to change over to saying NAW-STIR like most other people do.
Phones have secure enclaves. If they did taproot schnorr secpk256 sigs (I don't think they do) you could use the secure enclave and not even see the private key in your own software.
I'm pretty skilled at missplling things myself
added issue #153
I could have a list of approved relays to read from to give the user a sense of more control. But then I would have popups saying "This event/person was not found, but I have reason to believe they are on this other relay XYZ. Do you want me to fetch them from there?" IMHO everybody will press 'yes' when presented with that question, so I don't see the point of asking.
When you first get started with gossip it often gets stuck and can't find anything. There is a good argument to be made to have "read" relays to get past this point, and I will probably have to do that.
There are different kinds of clients. One kind connects to a community relay (or more than one) and operates like IRC, and hears people only on those relays. The other kind (my kind) operates like a web browser, and if a webpage references a resource at a web server, it goes and gets it, without the user having to setup a list of approved webservers from which to fetch resources.
Gossip has write relays - that is where you post and I think users *should* manage them. Gossip doesn't have "read" relays. It finds people and events wherever they are, and uses a lot of things to do this (but not randomness) including kind2, kind3, kind10001, nip05, nip23, p and e tag hints, previous success with that pubkey at that relay, and also relay statistics (number of successes versus number of failues, hangups, etc).
The one I'm building called gossip doesn't publish following lists (yet).
Oh, and followed (my public follow list is wrong, I dont update it)
When events refer to people (or other events for that matter) without a recommended_relay_url and which are not present on the relay which served the referring event.... then you might be kind of screwed. I've been battling this myself. I keep event-relay and person-relay associations in a database based on everything the client has ever seen, and look up those associations and hope. But sometimes there are none to use (especially when starting off). I really appreciate clients that fill in the recommended_relay_url field. So far I haven't fallen back to the "configure read relays" fallback solution, but that does work in today's nostr environment better than you might think.
Dont forget #[1] #[2] and yours truly
Oh no, nothing like that. In fact I've only found these "bad" keys in nostr.json files. If they showed up in events I would be getting deserialization errors all over the place. I really think it's just a mistake, someone mistyping their key, but I thought I would ask.
It was also news to me that the public key space isn't all of the 32-byte numbers, even though the private key space seems to be (all but the number zero).
Ok, start typing a name into it. You'll get a little button below it like [@] which is a pulldown menu of the matches, if there are any (it is limited to people in memory atm IIRC). Select a match. You'll see it added to the p tags (listed under the draft) and it will insert a placeholder for you.
Cool! I'll check it out when I'm awake.
Tagging #[2]
I think this will make a big difference. Relays could then subscribe to this aggregation service for counts and then embed those counts into the events as they serve them as suggested by tmathews on github, and that way most clients wouldn't have to make additional queries.
(MIned keys + blocking spammers by key + (IMHO) blocking events that are not recent) seems like a good strategy as long as there is no cryptographic issue with narrowing the keyspace subtantially. I'd love for a cryptographer to let us know, because if it's okay, then I think this is a really good idea.
I remember the Hello Nostr thing that people were talking about but I didn't happen to see any. But it also might have been a very busy week for me offline.
I was hoping to subscribe to a service like you might do with a pihole that blocks ads, or an email provider that blocks spam. One that maintains a good reputation for being limited in their scope, who doesn't block political content they disagree with. Should such a service arise and suggest a protocol, I'll plug gossip into it.
I agree so much I liked this post twice
That would be a big performance improvement, but clients don't trust relays.
Ok I suppose I thought a bitcoiner was an enthusiast. I stand corrected.
Gossip has a relay picking algorithm. Usually I can follow a couple dozen people by picking just 3-5 relays since people post to multiple and tend to congregate around some like we’ll order or Damus.
So do I. I think it is the egui. I get one core hot if I keep moving the mouse it keeps rerendering. If not it quiets down.
I'm no cryptography expert though so I cant't explain to you how the key combination actually works.
It uses ECDH (the NIP probably should be more explicit)
I'm no cryptography expert though so I cant't explain to you how the key combination actually works.
Keys are combined with ECDH (Elliptic Curve Diffie-Hellman) which essentially is a kind of multiplication operation
Another test post (this is so cool)
test post