Avatar
Mike Dilger ☑️
ee11a5dff40c19a555f41fe42b48f00e618c91225622ae37b6c2bb67b76c4e49
Author of Gossip client: https://github.com/mikedilger/gossip Dual National (USA / New Zealand) My principles are Individualism, Equality, Liberty, Justice and Life

This reflects that the people who believe that experts know more than them parrot the views of the experts, and the people who believe they are smart enough to think for themselves about one thing (vaccines) do so for other things as well.

This reply should have a content-warning. Let's see if it does...

Let's hope it was just this one time. I don't recall eating a bucket full of shrimp or anything else with high purines though.

Replying to Avatar n

gossip doesn't implement custom emojis.

Replying to Avatar Alexander

I can't recreate it now, but maybe when I started to use Gossip, it wiped my relay list: https://void.cat/XstoUBMsRSxPZWQKBB78Cj

Screenshot from https://metadata.nostr.com/

If this is unexpected, I could try replicating it by rebuilding Gossip from the source and opening a GitHub issue if it occurs again.

Yeah it looks like gossip didn't get your relay list, so it was starting a new one with 'wss://relayable.org/' which wiped your previous relays. This is a problem in other clients too, and it's hard to solve if a client can't find your existing data. I have put more safety around making sure contact lists don't get clobbered this way by making it entirely manual and showing the user what is happening, but I haven't done the same thing for relay lists yet.

Oh fun, another milestone to celebrate: gout

If you are looking for rainbows and unicorns, you've made a wrong turn

laptop? webcam? I don't know these words.

Anybody get bitcoin core to setup an onion site for listening from within qubes-whonix? [I can't find the tor rpc control ip/port... or is it more manual than that?]

Anybody get a coldcard to work in a Qubes VM without attaching the entire USB controller to the VM?

When you say "gossip is removing relays" do you mean the relays on the live page? They only get "removed" if the relay disconnected. Gossip doesn't disconnect. Gossip doesn't go straight away back to relays after they disconnect - if it did, it could get into an infinite loop of disconnecting and connecting. So it gives those relays a 30 second cooldown, and in the mean time looks for other relays to serve the same purpose. A lot of work went into dynamically managing these connections.

Here are a few tweaks you could apply:

Under Relays > Configure, you can set the "Read Rank" very high (e.g. 9) and then that relay will be significantly preferred for people who post to it.

You can also just tick the box in the 'Read' column, although that is only used as a fallback if gossip can't find relays that the person posts to.

Under settings, you can change the number of relays to query per person (I like 2, but you could go higher for more redundancy) and the maximum relays for following (I think this should be very high, right now I use 50, but as nostr decentralizes I will bump it up higher).

Databases are either general purpose and therefore aren't optimized to the specific situation (e.g. sqlite3, which isn't even very concurrent) or else they are massive things that can optimize into a plethora of different situations (e.g. postgres). So you either suffer the "not optimal" or the "massive". By rolling your own, you suffer neither.

I'm doing it because it is fun and is a learning experience. I am well aware that I am reinventing the wheel. My brother is a core postgres developer. We have spoken on the phone and he understands what I am doing and says that it is similar to what postgres already does and why don't I use postgres? Because I wouldn't learn anything if I just used postgres. And it would be massive and a deployment nightmare.

I'm using sled (a key value database) as the underlying technology of my indices, so strictly speaking I am using a database and I'm not entirely reinventing. The remaining parts that I chose to write myself were not too difficult. The specific use cases of a personal nostr relay are rather constrained so I can optimize for them fairly quickly without it taking months of work.

Put me on the wait list for the next available robotic girlfriend... but I want the model that cleans the house.

There has to be some kind of key replacement that is better than that. We know of solutions better than that (e.g. NIP-41, the other NIP-41, NIP-109, NIP-101). But I don't think the community has settled on one. So I'm not 'on the hook' yet... it's just something I think gossip really ought to support once the NIPs have settled on the issue.

Instead of using a database I'm storing events in a file. Memory mapping lets you access a file as if it was entirely in memory, and the OS pages it in and out for you automatically doing the reads and writes and stuff.

Each event just gets appended, which requires a write lock (one writer at a time) but readers can keep reading while writes are happening so it is less contentious than a traditional RWLock which blocks readers while writes happen.

The indexes are functionally similar to key-value btrees which map certain query tuples like (pubkeyhex, createdat, idhex) to an offset into the event file (the length of the event is encoded in the serialization so we just need the offset). The serialization is very minimal, just enough to have a length and to be linear. Each key in each index must be unique (or else we would lose events) which is why they end in the "idhex". We can scan a time slice (before/since) as they are grouped together on the btree, so I can iterate from (pubkey, before) to (pubkey, since+1) to get all that person's events within that time range. I'm intersecting multiple index results by hashing results and checking that map each time I run through the next index, discarding matches that come up missing (from the previous index). That should cover all possible queries, not in an ideal way, but in a simple and relatively fast way. strfry has more indices (all the common ones) and falls back to scanning a flatbuffer event sequence for matches. It also uses LMDB for the events rather than trying to memory map directly. I'm using sled for the indexing. I don't know if my indexing merging scheme is going to be faster or not. Probably slower in most cases, but faster then when strfry doesn't have a suitable index. That's my guess anyhow. My code is at least easy to reason about. I came up with mine before talking to Doug.

My brother told me it took him more than a year of working on postgres to truly appreciate how many manhours have gone into it and how optimized it is for so many different kinds of situations... and that I will never be able to match it starting from scratch... and that avoiding theq SQL parsing and query planning isn't going to pay off when the data statistics change and my hardcoded solution becomes wrong... but he did understand the desire to have a much smaller thing without all the crap I'm not going to be using.

A lightweight relay that works as a READ and WRITE relay, but only for messages related to me. So people can send me things (to my READ relay) but nobody can read them back. And anybody can follow what I WRITE. I looked into nostr-rs-relay and strfry and neither are easily tweakable to do this, but probably easier than starting from scratch.... yet, you know me, I want to start from scratch in rust, it would be fun. So I did, and got the very basic memory-mapping and lock-free concurrent indexing code working... ya know, the hard part, the fun part... and now I can't be bothered to finish the boring part.

I haven't. What about you? I don't see coracle listed as an OpenSats project (I do see they have a nostr fund though). By HRF do you mean the Human Rights Foundation?

Almost all the recent gossip development has been by nostr:npub1hlq93jdtkfg29a8s7fqzzzh82q3pkc20rxucwt4geh6e56wk3y2qxdz5wg with nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk doing design. Those guys deserve zaps.

I'm going through a "pinch point" where my life is really busy (finishing the house, 3 sets of taxes, too much firewood, truck/insurance issue) but I swear I will get back into gossip development (and other nostr-related things like NIPs and my personal relay idea) as soon as I can and finish the most important things (zaps, syncing settings on the network, media cache expire/etag/etc, inbox feed to include if tagged in content, reposting, finish search, DMs, some kind of key rotation/recovery scheme, way better at-mention UI, plus whatever new NIPs I've missed that are relevant and important)

The improvements Jack speaks of are on the master branch, not yet released.

The improvements jack speaks of are on 'master', not yet released.

Would you be suprised if Russia struck a US military target outside of the Ukraine (A US military base in Poland, for example) after Ukraine used US supplied F-16s to strike at Russian military targets inside of Crimea? Or would you think that is an escalation too far that Russia would not make?

Just curious what people think. I'm thinking they would. I think Russia would feel that it needs to destroy US military assets in exchange for the destruction of Russian military assets (outside of the theatre of Ukraine), and any lesser move would amount to accepting an asymmetric loss.

And because I think the US understands this, they do not want Ukraine to strike such targets, they want to keep the war within the defined theatre. But then I think Ukraine might do it anyways, pissed at both sides and wanting the war to move outside of their borders.

Yes, that was all just speculation. I find it fun to think through the scenarios.