Should I be putting the "nostr:" part? I honestly don't know if other apps are parsing those URLs. If they are, great, I'll add it.

true. we must chase.

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

Send them all at 11pm

🤙

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.

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 {}

pub trait WebsocketHandler {

type EventStream: NostrEventStream + Unpin;

/// Write a text message to the websocket

fn write_text_message(

&mut self,

message: &str,

) -> Result>;

}

pub async fn fetch_event(

websocket_handler: &mut W,

id: IdHex,

) -> Result, Box> {

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

Should gossip send these to your system configured URL handler? Should gossip also work as the system-configured link handler for the 'nostr' scheme?

Congratulations fellas, great work.

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.

/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.