Yeah, I was far too categorical. There are many reasons. And I disagree with Peterson on the whole. But I highly doubt he would be swayed.


I'm pretty sure he does. He's a psychologist, it's his field to know about human behavior.

I think nyms are only needed if your government seems likely to become very oppressive in the near future and punish you for past political wrongspeak. That's unfortunately true in all Western countries right now.  The unfornate downside is much less self-control over one's behavior.


I'll process this when I get home. Have to mine fiat atm.


This is one reason I don't thing nostr should contain multimedia. They would come here and put a target on us.


I would prefer a new kind 10002 like this:

    id = id
    pubkey = pubkey
    created_at = created_at
    kind = 10002
    tags = [
       [ "r", "wss://nostr.mikedilger.com" ],
       [ "r", "wss://nostr-relay.wlvs.space" ],
       [ "r", "wss://nostr.fmt.wiz.biz" ]
    ]
    content = ""
    sig = sig

That means "I (pubkey) post to these 3 relays."   I spread this far and wide so people who wish to follow my content can find my content.


> If you have this then you have the censorship problems we've seen solved (we don't need Carmen Sandiego clients that try to stealthy find our censored follows). Your follows list(s) can go with you but you do not need to abdegate clever stuff to your client that hides it all from you and asks you to trust it.

I want to follow Steve Bellovin but I don't know where he posts.  So I ask several "bootstrap" relays  to get his "relay list" (relays that specialize in just storing relay lists).  One of them serves it to me (because he sprayed it far and wide).  I can now see on his "person" page in  my client that he posts at A, B, and C.  Ok, now I can manually surf to A, B, or C and see his posts (or in my client you don't have to it just shows up in your general feed... but I don't want to argue that point, it's immaterial).

The client doesn't need to do any clever stuff (gossip is far too complex).  It doesn't have to hide this "relay list". It can be right there, an event you can view in raw form if you want.  It's pretty simple, but it requires a paradigm shift of spraying our relay lists and clients using them.


I think that is a great model.  Make relays front and center, and users travel around browsing them.

I also think some users want to know "What is Edward Snowden saying?" and they don't really care where he is saying it, they just want the "it" being said.

So we need multiple models working in parallel.


Interesting. This allows people to move around rapidly. However, what if I want someone's events spanning a longer time period?

It's the same problem of following threads across multiple relays which isn't fully solved either.


I interpret kind 2 to say "Hey this is a great relay, you guys should try it", rather than "If you want to find my posts in the future, I expect to be putting them here".  kind-2 also only has a single relay in the contents.

kind 10001 in nip 23 (pr 32) would work.  I'm not excited about parsing the runes language, but it would serve.

Currently gossip does excessively complex tracking of stuff because "here is where I post" information is not easily and widely available.


I am in favor of "spraying" relay lists, and posting regular events to just 2 or 3 relays.  Even if you get booted from all 2-3 of your relays, just spray your relay list again with updated information and people can find you again (once clients start following people instead of following relays).

It might also be useful to have "bootstrap finder" relays dedicated to accepting and serving only relay lists.  Spray to those so you can be found.

The spray isn't very bad because it is just 1 event per relay per person (a replaceable event).

I'm in favor of kind 10001 or similar relay lists (using the contents of kind-3 Contact lists is heavy-weight because Contact lists are huge).

This is a refinement of my thinking and not something I've explicitly said elsewhere yet afaik. #[1]


Yeah. I think posts should show where they came from ideally without needing to click a pulldown.  But I'm trying to figure out how to make it not take too much space at the same time.


You don' t have to pull everybody's messages from all 40 (or 500) relays.  You can pull them from just N (I use 2 or 3).  That way you aren't getting massive duplicates.


Oh!  I see.  He will get far with that one. 😆


I was just mentioning something someone else was talking about. I also don't know anything about DHTs. These are just words I hear bandied about when talking about services that help people find people.


There has been some chatter about services that specialize in bootstrapping like this, DHTs, nprofile servers, etc.  I'm staying out of the server-side of things, but happy to subscribe to such things when they exist.


For writes, users manually choose. I think this is going to be more and more necessary as relays start requiring subscriptions.

I think posting normal messages, just a few relays.  For posting your relay list, might be smart to post it to many relays so more people can find you.  I'll be adding something for that.


#3 is probably leveraging the position to make money


I was just about to take a few days off.. but now you've said it improves daily.  *sigh* I guess i have to keep improving it daily then.

jk.  Glad you like it. 😀


I think that if we want a non-technical userbase, there is only so much configuration they will tolerate.  So for clients that cater to regular people like Damus, it's reasonable to hide some of it.. but not all of it.  I think users should definitely choose where to post... choosing where to read from is less concerning, but if a relay starts censoring someone you'll want to find their stuff elsewhere.  So there needs to be a way to dig into the settings and adjust things, but it also should "just work" for those many people who never dare dig into settings panels.


Related: https://bountsr.org/design/2023/01/26/relay-based-design.html


🤙
It was there, I just mistyped the emoji list in my post.


I haven't considered that. I'll put a tag for that on issues at some stage soon.


Opened issue as https://github.com/mikedilger/gossip/issues/171

Would all the npubs be living on the same relay?  If not, might want to import nprofile in batch (nprofile associates relays with the npub). If so, however, the import function should let you specify a relay for them all while importing.


Done. Latest push puts QR codes on the person page for npub and lud06 if available.


Glad. I can focus elsewhere then. There are so many fish to fry.


The other thing is all the emojis are black-and-white rather ugly ones. I really want to use NotoColorEmoji.ttf, but ab_glyph (used by egui) doesn't support fonts with color tables: https://github.com/alexheretic/ab-glyph  so either (1) we inspire Alex Heretic to add support for color tables, (2) we work around it by drawing color emojis onto a GPU texture and hack into the text rendering stream, or (3) we switch egui to use a different backend renderer like swash (if that is even ready I dunno), or (4) we ditch egui and rebuild gossip's gui (which is not too tightly integrated).


Yeah, definitely a major shortcoming at the moment. I cut-and-paste (with CTRL-v, not unix middle click) from another app: 🤙.

Eventually I'll stop and think about how to build an emoji picker...  but my dream is if someone else who had the aptitude for UI helped out on the UI parts of gossip.


The QR code thing basically renders the entire note as a QR code. I put it in so I could pay LN invoices with my phone.  I still need to add it to other places, like for following people or for metadata lud addresses.


I'm still playing with it to. All feedback much appreciated.


The content of the post becomes a QR code.  I think I still need to 'trim' it first.  It doesn't search for 'lnbc', it just QRs the entire post.


When a note refers to a person (p-tag) or event (e-tag) there is a second parameter (3rd string in the array) that is the recommended relay where clients might be able to find that person or event. It's optional, and data is unreliable (that relay may die, have deleted it, be captured by the government, the author can lie, or whatever), but it is helpful when it works. Otherwise oftentimes the person/event cannot be found because we don't all use the same relays.  I think having these in the tags that refer to other things is the right place, so I don't think there's any use in adding more relay pointers to events outside of these tags.


Yep, can't find her. Don't know who we are talking about. I just see an npub.


pub trait NostrEventStream: Stream<Item = Event> {}

pub trait WebsocketHandler {
    type EventStream: NostrEventStream + Unpin;

    /// Write a text message to the websocket
    fn write_text_message(
        &mut self,
        message: &str,
    ) -> Result<Self::EventStream, Box<dyn std::error::Error>>;
}

pub async fn fetch_event<W: WebsocketHandler>(
    websocket_handler: &mut W,
    id: IdHex,
) -> Result<Option<Event>, Box<dyn std::error::Error>> {
    let mut filter = Filter::new();
    filter.add_id(&id, None);
    let message = ClientMessage::Req(SubscriptionId("fetch".to_owned()), vec![filter]);
    let wire = serde_json::to_string(&message).expect("Could not serialize message");
    let mut stream = websocket_handler.write_text_message(&wire)?;
    Ok(stream.next().await)
}


I think that might be a long conversation. But maybe I'd get there faster.


Thanks.

I've tried several times (unsuccessfully) to build another library on top of nostr-types which provide a futures Stream<Item=Event> over a websocket listener, provides high-level actions that use it (like post, fetch a post, fetch a contact list, etc), and allows the consumer to plug-in their own websocket listening code as long as it implements the Trait I need to drive it. That would be the library to build new clients on.  But it's rather tricky to write that kind of rust.  I may not be quite smart enough, or maybe I've just not succeeded yet.


I'm presuming they are simply unaware. I think a nip like #[4] NIP-24 would at least alert client authors that they can't just clobber stuff.  Then NIP-23 can come along when it is ready.


If you copy his picture and bio, it would be harder to tell. But I would still see that I'm following him and I'm not following you... although it isn't super noticable in gossip currently.

In the past people suggested using colors/images determinstically generated from the public key. Those would change and be more visible noticable.


Looks fake to me.
https://nostr.build/i/nostr.build_7555.png


/e/ is a European attempt to build an AOSP that doesn't depend on Google.

GrapheneOS is an attempt to make a very security hardened version of AOSP.


Hey #[1], I got a few DMs from you 4 days ago I just noticed, and they aren't decrypting (on snort.social). If they are still relevant, maybe try them again.


#[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.


I could be wrong. I'm not actually a UK English teacher.


I'm pretty skilled at missplling things myself


added issue #153


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.


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.


My point being that it is mostly a relay misuse/DoS issue at this point.


I have yet to see a single spam message. The relay operators must be doing a good job, or the spammers must be incompetent (Maybe that's because I don't browse general messages anywhere and am only introduced to new people if they are in a thread with someone I already follow. #[7] says most didn't use the canonical note "kinds" - I would never see such).


I agree so much I liked this post twice


I'm going to correct myself and say that PoW and tightly bound timestamp checking together might be robust enough to not require in-protocol AUTH, but in-protocol AUTH would be more reliable.


Then accept fiat to pay for usage. People pay USD (for example) up front and their balance slowly drains.


PoW doesn't stop event aggregation. Event aggregation of valid events with PoW, can become a denial-of-service attack. Most relays don't want to host every event from everywhere, but clients want them to so that they only need to connect to that one relay.

Charging LN is also going to need to be done in a way that doesn't just look at the pubkey of the author, but uses protocol messaging to ensure that the author is the one trying to host the event, and not someone else replicating it.


I think paid-for relays is eventually how things will have to go, else they will be flooded, and not just from spam but from people trying to aggregate events into the relays they listen to.

I would do N satoshis per kb, rounded up.  Most events costs N, but long events might cost 2N or 3N or more. I agree that with a paid model, you don't need size or frequency caps.


That would be a big performance improvement, but clients don't trust relays.


All of it. It all needs work.


So if you come into possession of the root, can you can query for all posts that have the same root in a single query using NIP-12? Rather than getting the parent, then the next parent, then ...


Dumping my thoughts here:

1. Look at public chat only on relays that filter spam effectively,
2. Spam filtering tools in clients (banning a key will probably be ineffective, but matching content patterns should work)

3. Friends of friends
4. Everybody buy ASICs! 😆


It uses ECDH (the NIP probably should be more explicit)


Keys are combined with ECDH (Elliptic Curve Diffie-Hellman) which essentially is a kind of multiplication operation


Not released yet  https://github.com/mikedilger/gossip


Brilliant. I'm stealing that idea.


Oh no I'm pink!


Another test post (this is so cool)


test post


Typescript, VueJS 3 and Rust (via Tauri which makes a portable webview-based local app like Electron but much lighter)


I hear ya!  I've just about got my desktop client which I started 2-3 days ago showing a feed (and keeping it updated) for the first time from multiple relays.  I feel like I just drove up a long winding hill and I'm about to hit the downhill strait.


Remember all the relays for a user.  1. If you are already listening to a relay in the user's list, use that one. Otherwise just pick one. 2. If the one you picked is down, choose another.


I https://github.com/nostr-protocol/nips/pull/73
#[2]


I started drafting a NIP for issue 70 to put relays in nip05. Maybe I could finish the draft and issue it as a pull request for comments.

But I see 2 other issues: some people don't want to be associated with a doman, and current clients aren't always doing the right thing.