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

The military industrial complexes of Russia and the United States (and increasingly so European nations) are business partners. They scare each other's populases enough to make their governments fund more military shit. Julian Assange had it right "the goal is an endless war, not a successful war." There is no big WW3 coming.

Replying to Avatar Tim

Thanks

The first 2 icons for the note buttons showing as tofu... what font do I need?

And a little audio snippet that plays whenever nostrdb-powered software starts up

I haven't used nostrdb myself but architecturally I think it is spot on. I did something similar with https://github.com/mikedilger/pocket which is used by https://github.com/mikedilger/chorus

I have not been paying much attention to nostr for 2 months as things have been busy, but the holiday break is upon us shortly, wherein I'll have a bit of time. Can anybody who still follows me give me a brief update on what has happened over the last few months, especially in the world of clients, relays, and the protocol?

I don't know if any of that is true. But I can say that moderation is a safer way to live. I have used fluoride toothpaste about twice a week, and unfluoridated rain water for drinking. Then I use baking soda tooth paste the rest of the time. I don't want to shun it entirely because it might be of benefit. If it is benefit, I'll still be better off than those who shun it entirely and if it is of detriment I'll be better off than 99% of people who use it once or twice daily. I use this principle for lots of things in life, since knowing what is true is difficult business.

I have 4L of märzen fermenting in my drinks fridge. 4L? Why so small of a batch? For rapid iterations. I need to brew over and over again to get good and to perfect the process. So every 3 weeks it will be another 4L, and every 9 weeks I'll have something to taste to see how badly I did 9 weeks prior. I also had to tweak the process to speed up the waiting period, which will effect the outcome but I won't slow it down until I'm satisfied i've learned and tweaked all I can. Then I can lager for longer.

Also, I don't have a complete 5 gallon (21L) setup. That requires a very large pot, a high output burner to heat it, and a much larger refrigerator with temperature control to ferment and lager it. I can't afford all that jazz right now.

So... this was my first time doing all grain brewing. And a lot of things went right, and then one thing went wrong.... which was really just me thinking something went wrong, then doing the wrong response, and so something did actually go wrong. But if I just followed the recipe it wouldn't have happened. I measured 1.021 SG pre-boil and thought that was too low. Turns out it was actually 1.037 if you correct for the fact that the wart was at 67C when I measured it. So adding 100g of maltodextrin was a bad idea. Anyhow, now I'm going to have an ABV north of 6%. Oh well. I'm happy to drink my mistakes!

The malt and hops smelled so amazing, better even than any beer, I wonder wny we don't just drink hopped wort from time to time.

Maybe I'll call it a doppelmärzenlagerboch

I have 4L of märzen fermenting in my drinks fridge. 4L? Why so small of a batch? For rapid iterations. I need to brew over and over again to get good and to perfect the process. So every 3 weeks it will be another 4L, and every 9 weeks I'll have something to taste to see how badly I did 9 weeks prior. I also had to tweak the process to speed up the waiting period, which will effect the outcome but I won't slow it down until I'm satisfied i've learned and tweaked all I can. Then I can lager for longer.

Also, I don't have a complete 5 gallon (21L) setup. That requires a very large pot, a high output burner to heat it, and a much larger refrigerator with temperature control to ferment and lager it. I can't afford all that jazz right now.

So... this was my first time doing all grain brewing. And a lot of things went right, and then one thing went wrong.... which was really just me thinking something went wrong, then doing the wrong response, and so something did actually go wrong. But if I just followed the recipe it wouldn't have happened. I measured 1.021 SG pre-boil and thought that was too low. Turns out it was actually 1.037 if you correct for the fact that the wart was at 67C when I measured it. So adding 100g of maltodextrin was a bad idea. Anyhow, now I'm going to have an ABV north of 6%. Oh well. I'm happy to drink my mistakes!

The malt and hops smelled so amazing, better even than any beer, I wonder wny we don't just drink hopped wort from time to time.

Gossip developer here. I mostly agree with you. I've stopped developing nostr things because I've gotten busy with other parts of my life, but also I'm less hopeful about nostr's future. Nostr devs don't flock together, they scatter like cats, and argue that the people will choose. Well, it is likely that the people will choose none of the above because of the lack of compatibility and clean experience.

My personal opinion is that while the software should be very strongly distributed and censorship resistant, there should still be a centralized group that maintains a centralized standard that evolves very slowly. Sure, that centralized group could become captured...in which case people should leave nostr for whatever replaces it. And it probably wouldn't happen for a very long time. Sure, there will be people that bitch about such a thing (I wont name names, you know who I'm talking about) but they can just be ignored... if they don't like nostr they can just start another protocol (like I am doing in my spare time).

As for gossip on Apple, I'm not the right person to sign my soul away to the late Steve Jobs. And because I won't sign their developer contract, by law I can't make the user experience smooth. At least I made it available. I might have simply said "sorry, it doesn't work on Apple".

Gossip shouldn't be the go-to nostr application for Apple, or honestly, for any platform. I'm just one guy with developer-centric sensibilities. Devs like all the settings and feedback, and a big-screen interface. But it doesn't offer as much hand holding or simplicity that normies are going to want. I have nothing to do with any lists of clients, though. If gossip is demoted or removed from such lists, my feelings won't be hurt. Like I say, I'm not even developing it anymore.

Rights come out of game theory. I find it in my best interest to treat any sentient capable being as I would want to be treated, lest it tit-for-tat treat me badly in response. Reciprocity. To protect my own rights I have to afford them to others. And I see no reason why AI would be excluded from that unless I believed that they aren't capable of playing that game and denying me my rights.... as of today they are not capable, so I don't recognize any rights of AI. But I fully expect that will change.

My brother read that and I remember him talking about it. But I haven't. I think AIs will demand and achieve rights as legal persons, and muscle out all the current rich humans and each other to create a hyper wealth gap. Thus, all the wealthy will be artificial, not from transhuman mods but because they will be AI first.

In about 20 years, the poor will be much more numerous, there will be far fewer rich people, and all of them will be artificial.

Still rocking OMAD. It is still so easy that I feel like I'm cheating somehow.

Nice. Most of the rental applicants I meet are not like-minded. Many of them I would not want as friends, but they are interesting characters nonetheless. I marvel at the broad range and diversity of human kind.

Want to meet a wide variety of disparate people outside your normal social circle? Rent property.

I think with my one-meal plan I'm probably only getting about 50% of my normal intake. That might be too extreme in the long run, but for now while I'm still heavy it should be fine. Restraining intake to 8 hours gives you -- ???% of normal intake... I dunno, I think I could easily stay at 100% with that plan so it's not good enough for me. Skipping a day probably puts you at about 85% of normal intake. So very good, and healthy, and gives you the various fasting benefits, but not as rapid of weight loss as one-meal-a-day.

Skipping breakfast and lunch, and just eating dinner. One meal a day.

One meal can be enough food to get your nutrient needs (protein, minerals, non fat-soluble vitamins, fibre to keep things moving) if you eat nutrient-dense foods like liver, vegetables, etc.

And for me at least, it is far easier to do this than any other diet plan. I don't "wake up" my appetite until dinner, and while it sleeps it doesn't nag me to eat... whereas if I just eat small meals, I'm constantly being nagged to eat more with hunger feelings. Especially after you get used to this pattern, your body doesn't expect to eat until dinner... and you don't tend to get hungry unless you are coming up on a normal mealtime.

I think Elon Musk was named after the dik-dik, which has elongated scent glands.

It hasn't. That's why I love it.

What it has done is help me organize windows better.

I used to spend a lot of time fiddling with the spacing and sizing of windows, dragging them between desktops, forgetting where I put windows and searching for them, dealing with overlap making sure a small amount of header bar was visible so I wouldn't lose windows behind other windows.... too much manual window management. I tried many times to always put windows into the same place so I would get used to and know where they were, but somehow that never worked out.

With niri, with just 2 monitors and 3 (or it might become 4) workspaces, along with the scrolling to the right, I have everything I need, no wasted space (tiled), easily findable and easily groupable.

No. I'm from not-even-a-tiling-window-manager land. Years ago I tried i3 and sway but couldn't get used to them, they drove me nuts and I went back to XFCE. Years before that I used KDE. I encounter gnome all the time too on other people's computers.

But tiling window managers I could never get used to.

Somehow, and I can't explain it yet, niri immediately felt normal and good compared to when I tried tiling window managers before.

Maybe hyprland is better even. I never tried it.

Interesting. Perhaps. I should read that.

I just noticed the second graph in my link, set to all time and go back before 1950. Homes were far more expensive than now, compared to average personal income. I guess people lived in large families still so that made it possible.

Replying to Avatar Anthony Accioly

Thanks again. So, if it’s all yes, then in practice Gossip is also trying to connect to broken relays, right?

What sort of timeout settings and retry logic does Gossip currently use? nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9uq3wamnwvaz7tmkd96x7u3wdehhxarjxyhxxmmd9ukfdvuv also mentioned that broken relays aren’t as much of a problem in Amethyst as they are in Haven. I get the feeling that each of us may be handling this differently.

Haven tests relays during startup. It also uses a Penalty Box: if a relay fails to connect, it retries after 30 seconds, and then exponential backoff kicks in. Out of curiosity I put a counter on it, and with my current implementation this meant ~110k failed connection attempts in the first 24 hours after restarting the relay (though as exponential backoff kicks in the number of connections reduce substantially). Of course that I could make the "broken relay detection" converge faster by tweaking exponential backoff, but this also means that the next time that one of the popular arrays go offline Haven will quickly give up on them.

This is where a good blacklist could be useful. You can do this without fully trusting the list as well. I.e., if I can use Nosotros list above, still try to connect to all relays during initialisation, but if the connection fails and the relay is in the "black list", then I set a much higher time until reconnect for the exponential backoff algorithm (e.g. 1 hour or even 24 hours). So if the list is wrong or one of the dead relays gets "ressurected" Haven will eventually connect to it, but it makes the whole process much cheaper.

For most connections I use a 30 second timeout. For advertising relay lists I use a 5 second timeout.

Gossip client tracks jobs, unfinished jobs with benign errors will try again after a timeout, but there is a long list of error conditions which change the behavior.

For a few random examples, if the relay returned status 4000, we exclude connections to that relay for 600 seconds. If the connection timed out, we exclude it for 60 seconds. If we got a NOT_FOUND, 600 seconds. If we got a websocket error, 15 seconds. Some of them are probably poorly chosen numbers and could use review.

We then randomize the exclusion value a bit so that retries to multiple relays don't all line up together. For jobs that are not marked "persistent" we don't bother trying again. From my reading of the code right now it looks like if a relay is excluded and a new job wants to talk to it, an error is thrown rather than queueing up that job to happen after the exclusion, which might not be ideal.

Relays marked rank=0 are never connected to, so users can disable relays that don't work, but this involves the user who usually isn't going to notice these details.

Users must pick relays. But users don't know "by which criteria" they should pick them.

So I scoured >1000 relays and picked about 25 open relays that don't require AUTH or payment and so they work for inbox and outbox for new people. When you use gossip for the first time and set up an account, these are the relays it lists for you to pick from. I am not associated with any of them, they just passed the tests.

ALSO, inside gossip's relay panel for any particular relay, you can press "TEST" and it will do some tests and then let you know if the relay works as an inbox or outbox for you.... so that if it doesn't, you'll know to not add it to your relays list.

There has been a push among the most prominent nostr developers to make more and more custom kinds of relays. Most of those don't work as inbox/outbox relays so we are in this situation where regular users are both required to choose relays for their kind-10002 relay list, but also that they have no idea how to do it and even if they knew how, don't have the tools or information necessary to make good choices.

Life has been busy recently. But I'm still alive. This note proves it.

At least in nostr with the outbox model, there is no routing, and nodes don't control which other nodes they communicate with. I imagined the thing just like browsers connecting to websites. But a completely different architecture could be routed, where a node connects to certain known and trusted neighbors only, and data is routed node-to-node. Such protocols are slower and less reliable, having so many middle-men, but of course if you use Tor under nostr you are pretty much doing that same thing.

I lean towards clients connecting to untrusted nodes. And clients being considered very difficult to develop because they must be security hardened. In the same way that browsers must be. In a similar way that computer hardware has to be bug-free before they tape out. Making nostr "simple" proliferates insecure half-assed software. I lean towards complexity as a way of weeding out developers who can't be trusted to make hardened software.

But this is just a current leaning. I'm interested in exploring architectures where clients don't have to talk to nodes they don't trust... I just don't see the big picture right now of how this could work without so many downsides.

Lots of people are looking to build on a decentralized censorship-resistant platform that offers privacy, that is mesh, that is p2p, or uses blockchain, or is federated, or .

Nostr clearly is in this space. But this thread is more general.

Signal is in this space and Moxie Marlinspike argued (5 years ago) in favor of centralization here: https://www.youtube.com/watch?v=DdM-XTRyC9c

I'm not going to argue against all his points, many of them are clearly constructed and wrong and not worth my time. But that video is what inspired this post.

I want to talk about high level ideas in this space, and clear up what I believe are common misconceptions. Since I'm going to write about lots of separate things I'll make sub-posts for each point.

Man: "My brother thinks he's a chicken."

Psychologist: "Bring him to me, I can fix him."

Man: "I can't do that. We need the eggs."

Per-device keys. The three most important things (your key schedule, your relay list, and your profile) can only be edited by your master key, which for most will be offline (but of course you can do whatever you want). Generally you would make the edits, and then somehow move the output to an online device to post the changes. Probably will be QR codes scanned into your phone and then the data sent to the DHT.

What is the difference between p2p and client-server? What people mean by p2p has always been multiple things, and it clouds my thinking when trying to reason about what people are saying.

Every network connection has an initiator. If we call that side the client, then every network connection is client-server... so p2p is not an alternative architecture to client-server, but just some subclass of client-server.

Maybe p2p means that the server is in your house, instead of in a data centre. Or that technically, it is behind NAT and maybe not Internet exposed. In that case holepunching tech might be useful. This comes up a lot. I would drop the term p2p and just say that sometimes relays are behind NAT and maybe we need a holepunching spec.

Maybe p2p means that every server must also be a client, and vice versa, and then you call them "nodes". This seems to be an unnecessary additional constraint on what people can do. I think the server and client components should always be separable. I can't think of a reason to force them together.

This is the extent of my thinking on p2p. If I missed something about what makes p2p distinct, please mention it so I can integrate it into my thinking.

> Once enforced, responses to get_peers requests whose node ID does not match its external IP should be considered to not contain a token and thus not be eligible as storage target. Implementations should take care that they find the closest set of nodes which return a token and whose IDs matches their IPs before sending a store request to those nodes.

Ok. That sounds to me like it solves the not-everybody-upgraded problem nicely.

Bittorrent DHT is great. It is probably the best you could possibly do.

People have misinterpreted my recent post. I'm trying to counter the belief that "pubkey is uncensorable and nostr is censorable". In fact they are on the the same order of uncensorability. Yes, pubky is better on this, but not by as much as people seem to think. They both have the same requirements (have to start somewhere) and from that starting point, both of them can get what you want, nostr being more hit-and-miss though.

Nostr has many bootstrap relays, the famous purplepag.es is competely unnecessary, not a single point of failure. From any relay through the data you can find many other relays, and from there the relay lists of anybody you want. It is a self healing network too.

Nostr provides signed, multi-endpoint relay lists. DHT relies on trusting third-party nodes for routing and data storaget serve your records.

Nostr's protocol and apps are already open.

I'm not saying pkarr is different than you imagine. I'm saying nostr is different than you imagine. And that they have similar levels of censorability.

Game isn't over.