Avatar
hodlbod
97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322
Christian Bitcoiner and developer of coracle.social. Learn more at info.coracle.social. If you can't tell the difference between me and a scammer, use a nostr client with web of trust support.

The mobile version doesn't work on either coracle.social or app.coracle.social? Which browser are you using on mobile?

Replying to Avatar hh

nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uq3camnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn9uqsuamnwvaz7tmwdaejumr0dshsqgyhcu9ygdn2v56uz3dnx0uh865xmlwz675emfsccsxxguz6mx8ryggtgu24 you may remember I complained that @coracle would take forever to load, maybe related to the nostr:nprofile1qyvhwumn8ghj7un9d3shjtnddakk7um5wgh8q6twdvhsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uqzq2elcsa8ln3q4cfr0zl3dx2nkw27q4w8jf5qgurw2nds3fydqyx9rhygy4 extension? A few days ago I figured out what caused it.

I used to use a shortcut to Coracle's site, which for some reason, some time ago, began to do what I said, and eventually became totally unusable (it just won't load).

Then, a few days ago, I was checking one of those compilations of Nostr apps, clicked on the link to Coracle, and it was almost instant. Then I noticed that the URL in my shortcut was to "app.coracle.social", while in the good one there was no "app" prefix, only "coracle.social".

So there you have it. Old link caused it.

Well, coracle.social and app.coracle.social run the same version of the code, so it sounds like it's probably still a memory leak of some kind. I don't currently prune the database, so it's possible heavy use could result in slow behavior. Are you on mobile or desktop? At any rate, let me know if it starts slowing down again — it's hard for me to test long-term usage because I'm constantly logging in and out.

Seed phrase vs nsec is one debate, primary key vs alternative keys is another.

Seed phrases and nsecs have trade-offs. I'm not super opinionated about one vs the other. But the more formats keys have, the more confusing it is for users. The ideal UX should probably be "paste your secret" and the client can parse it as a hex private key, nsec, or seed words.

On primary keys vs alternative keys, I definitely agree that the ability to make single-purpose accounts is important. But the most common use case for chat is to start a conversation with someone you already know, which requires knowing their user id. Otherwise you lose the advantage that having a social identity layer gives you.

Maybe if you want to surface that decision, you could start the app in "secret mode", which encourages one-off identities, or "easy mode" which asks for their existing nostr account and allows for social discovery.

Speaking for myself, I would almost always use the insecure mode. Conversations partners knowing who I am is a feature, not a bug. If I ever do need to contact someone secretly, I should be able to bootstrap a fresh key from my normal social context without revealing my identity.

Yes, and I was carrying a freshly caught salmon.

The relay stuff is definitely a work in progress (both from a protocol point of view as well as on coracle). The idea is that kind 10050s are a relay list specifically for DMs (see NIP 17 for details), and clients aren't supposed to send messages anywhere else. Coracle only looks at inbox relays when fetching DMs, which is likely why you didn't find the test events.

Looks like rosecoco.site isn't working, but I'd love to take a look

Replying to Avatar JeffG

GM Nostr 🌞

🆘 I need feedback on an idea related to private group messages.

I'm working on the format for sending group messages via relays and had an idea on how to encrypt messages in a way that saves a lot of work for both relays and clients. But it has some tradeoffs. Here's how it works:

1. Imagine you have a group of n people. The group has an ID value (random string) and each group has shared context that means they will know how to decrypt messages but if you're not in the group, you won't be able to decrypt. This shared context rotates regularly, ensuring forward and PCS security.

2. To avoid having to send each participant a gift-wrapped message, we encrypt the message content using shared group secrets and put that in the content of a Nostr event. This is an encrypted blob that is NOT using NIP-04 or NIP-44 encryption, instead it will be using MLS native encryption which has information about the sender as well as the message content itself. This event is published to group relays using a disposable identity, not the user's main nostr identity.

3. We put the Group ID value in cleartext in an indexable tag on the Nostr event.

This last point is important. Let's break it down:

– Clients only have to publish a single event to send a message to all participants (nice) ,

– It's trivial for members of a group to watch for messages they care about via a tag filter (very nice) and ;

– (the tradeoff) Observers can see how many messages are being sent within a group and when they're being sent but they can't tell who is in the group or who is sending the messages.

I think that this is a fairly reasonable tradeoff. I'd love to hear thoughts or — even better — suggestions on how to improve this.

This is almost exactly how my proposed NIP 87 works, except the group is recognized by p-tagged recipient, so members check directly for all keys for the group that have been shared with them. But I thought MLS solved this through the hierarchical key derivation stuff? My impression was that MLS made it possible to make the number of messages that need to be sent scale logarithmically with the number of recipients, without resorting to shared keys.

Replying to Avatar Charlie Fish

https://gist.github.com/fishcharlie/4197914636ce17a8e2817d2537ea3eeb

Here is my code. Ran this code, expected to receive a message on this npub when using a client that supported NIP-17. But didn’t receive any messages. So not sure even how to begin debugging.

Swapped out my pubkey for yours, and it worked just fine first try. My best guess is it's a relay selections issue. First, make sure damus isn't rate limiting you when you send the message, which can happen sometimes. Second, make sure the client you're using is asking for DMs on the correct relays. In Coracle, you'll want to mark damus as an "inbox" relay in your relay settings.

A prototype lives at keypub.coracle.social

It would be nice to get people with lots of experience designing decentralized software into nostr development too

It absolutely could. I'd ideally like to modify the UX to be more than just a list of posts though to include number of recent posts, amount of engagement among your follows, whatever. But a DVM would make this available today in coracle

Yes, that would be a step closer. But that feels like a lot of band-aids to get what blossom has out of the box, and by design. no_transform would also still only be opt-in, and the spec says servers can reject those requests. NIP 96 gives servers too much latitude to have a strong guarantee of referential transparency.

No, but coracle does strip metadata and compress images prior to uploading. There's no reason you couldn't extend that behavior to involve another server. Seems like a good idea to me, but I'm not working on file hosting to avoid getting spread too thin.

Unsubscribing from discussions about NIP 96. It's getting increasingly chaotic, and I think blossom is much better. If not because of the technical details, then because it's being built by people who really understand the strengths of nostr's architecture.

Surprised to find myself enjoying the new ghostbusters movie

Replying to Avatar Alex Gleason

Oh, you're here? We should hang out.

What is this, static typing for ants?

Thank you, that means a lot! Tgfn does have an account, but we don't manage it very actively: npub1mlcas7pe55hrnlaxd7trz0u3kzrnf49vekwwe3ca0r7za2n3jcaqhz8jpa

Replying to Avatar deeter

Will take a gander when I have a moment, great meeting you yesterday!

Wish I could help, but me and mine are turning in early

Absolute calm in the face of a dying battery, inspiring.

The FROST stuff is cool too. Could be a useful custodial model, where you trust each of several custodians with a different key.

Attempting to not get distracted by my own product:

Nostr protocol development:

People are using Coracle's custom feeds! Here are some interesting ones:

nostr:naddr1qvzqqqrujgpzp75cf0tahv5z7plpdeaws7ex52nmnwgtwfr2g3m37r844evqrr6jqyghwumn8ghj7vf5xqhxvdm69e5k7tcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uq3xamnwvaz7tmjv4kxz7fwvcmh5tnfduhsz9thwden5te0wfjkccte9ejhs6t59ec82c30qyf8wumn8ghj7un9d3shjtn5dahkcue0qy88wumn8ghj7mn0wvhxcmmv9uqpqvenx56njvpnxqcrsdf4xqcrwdqufrevn

nostr:naddr1qvzqqqrujgpzqlxr9zsgmke2lhuln0nhhml5eq6gnluhjuscyltz3f2z7v4zglqwqyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3eryvfwvdhk6tcpr4mhxue69uhksmm5wf5kw6r5dehhwtnwdaehgu339e3k7mf0qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr4mhxue69uhkummnw3ezumt4w35ku7thv9kxcet59e3k7mf0qyt8wumn8ghj7cn9wehjumn0wd68yvfwvdhk6tcprfmhxue69uhkummnw3ezuargv4ekzmt9vdshgtnfduhszxnhwden5te0wpex7enfd3jhxtnwdaehgu339e3k7mf0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcqzycrgvpsxy6nwwfhxqer2wpjxycrx895qk5

nostr:naddr1qvzqqqrujgpzqczwjmsfnym2zpyg89vtqs95weewpuzgex9v0yln0llycusz084jqyghwumn8ghj7mn0wd68ytnhd9hx2tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszymhwden5te0wp6hyurvv4cxzeewv4ej7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgawaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6tcppemhxue69uhkummn9ekx7mp0qqgrvdps8ymnqvf3xcersdfhxqmryx9hdms

nostr:naddr1qvzqqqrujgpzq3an3axnwgfep4dkhmmcmt3l8cug3mxm7xzylwenhzrjr5mx6hygqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg3waehxw309ahx7um5wgh8w6twv5hsz9mhwden5te0wfjkccte9cc8scmgv96zucm0d5hszrnhwden5te0dehhxtnvdakz7qqsxgurwdpkxg6nwdf58qer2ve3xvwjjnjg

I encourage you to try it out — create your own and paste its address into a reply to this note to share it.

Relay hints are like blastr - a short term solution that will fall apart over time. I stopped reading them a month or so ago in favor of better outbox model support. No pain, no gain.