🥹
nostr:note1k7094gqdy6f6jh0ahxuwyqqr7h5qkrzul3gd0nu32y0j57j6j7lq5nnpwn
Any public network exposed infrastructure can be DoSed given enough resources. Bigger and more scalable infra can just sustain higher load, making a successful attack harder / more costly. That's why even medium-size commercial businesses hide behind something like Cloudflare.
So the way I think about it - the more efficient the underlying protocol, the more robust it is in face of a heavy load (legitimate or malicious), but ultimately if you're running a relay on puny VPS, it will fail relatively easily. The goal is to squeeze as much as possible from what's available.
Low barrier to entry doesn't not have to mean low robustness. Often does, but ideally something robust could be easy to build on.
I was thinking about nostr, a bit from a similiar perspective, especially that a lot of things are very much like in https://github.com/crev-dev/cargo-crev (exchanging documents signed by self-generated identities). The purpose was different, but most things are analogous.
Agreed on everything, but with a note that ease of building client is a huge benefit, especially for a protocol that lives or dies based on network effect. The idea would probably not catch on if building things would require too much work. If it is to be more complex, it needs to come with good off-the-shelf libraries to use.
End user software delivery is the biggest constrain on boostraping. Being able to handle everything from a web-client (primarily) is a must have. And it must work well.
The transport layer is a secondary thing. Self-signed document can be delivered in various ways - through web sockets, raw tcp, bittorrent, with e2e encryption or without it. In carg-crev github repositories are used free and public transport. Relays could support combination of all and it can be iterated on. So I would leave websocket with TLS as is to start with.
Using faster and more compact encoding and crypto, detaching the signature (witness) would be the biggest wins, and can't be easily iterated on after the fact, so getting it right is important. Good engineering suggest using some "one byte-prefix for version", to allow ecosystem rotate to something else in the future.
Identities/crypto should be modular (just add a "type" prefix). Clients that don't support certain ID type, can just ignore the message. That gives an ability to rotate to something else in the future, without changing too much elsewhere. I'm not a fan of GPG/SSH (even though I use them all the time, every day). Being able to support it for clients that need it for something - great. Forcing on everyone - meh. Something that is fast and easy to support would be a preferable default.
Also, IMO, nostr needs to come with a portable, reference WoT handling library. Coming up with a well working WoT is quite complex. Different clients could come up with their own approach, but having something off the shelf that clients can use to get a reasonable and consistent WoT behavior would be a big plus.
In cargo-crev there's a `crev-wot` https://github.com/crev-dev/cargo-crev/tree/master/crev-wot that implements a basic Wot based on "trust levels", "distance from root" with support for bans and overrides, but I always wanted to (and never had time) to implement "maximum flow" algorithm to deal with sybil attacks and bot farms.
BTW. The websocket thing is something I wonder about often. In a use-case with reasonably frequent updates, is it better to have clients hold an active but mostly idle tcp connection (like websocket), or make them do polling, or some long polling?
A proper async IO runtime can probably handle tons of connections at once anyway. 10k, 100k, maybe 1M.
Also with a gossip-like note fetching, it should be feasible to have lots moderately sized relays, without a loss to usability, so maybe worrying too much about scaling vertically a single relay is unnecessary.
Otherwise some client&application level load balancing might fix the problem. Eg when connecting to a relay it answers with a list of keyspace "shards" (possibly overlapping for redundancy), and then connects/queries to the actually node that holds the data. That would allow reasonably simple and flexible scaling of the relays without complex server side load balancing.
I was thinking about nostr, a bit from a similiar perspective, especially that a lot of things are very much like in https://github.com/crev-dev/cargo-crev (exchanging documents signed by self-generated identities). The purpose was different, but most things are analogous.
Agreed on everything, but with a note that ease of building client is a huge benefit, especially for a protocol that lives or dies based on network effect. The idea would probably not catch on if building things would require too much work. If it is to be more complex, it needs to come with good off-the-shelf libraries to use.
End user software delivery is the biggest constrain on boostraping. Being able to handle everything from a web-client (primarily) is a must have. And it must work well.
The transport layer is a secondary thing. Self-signed document can be delivered in various ways - through web sockets, raw tcp, bittorrent, with e2e encryption or without it. In carg-crev github repositories are used free and public transport. Relays could support combination of all and it can be iterated on. So I would leave websocket with TLS as is to start with.
Using faster and more compact encoding and crypto, detaching the signature (witness) would be the biggest wins, and can't be easily iterated on after the fact, so getting it right is important. Good engineering suggest using some "one byte-prefix for version", to allow ecosystem rotate to something else in the future.
Identities/crypto should be modular (just add a "type" prefix). Clients that don't support certain ID type, can just ignore the message. That gives an ability to rotate to something else in the future, without changing too much elsewhere. I'm not a fan of GPG/SSH (even though I use them all the time, every day). Being able to support it for clients that need it for something - great. Forcing on everyone - meh. Something that is fast and easy to support would be a preferable default.
Also, IMO, nostr needs to come with a portable, reference WoT handling library. Coming up with a well working WoT is quite complex. Different clients could come up with their own approach, but having something off the shelf that clients can use to get a reasonable and consistent WoT behavior would be a big plus.
In cargo-crev there's a `crev-wot` https://github.com/crev-dev/cargo-crev/tree/master/crev-wot that implements a basic Wot based on "trust levels", "distance from root" with support for bans and overrides, but I always wanted to (and never had time) to implement "maximum flow" algorithm to deal with sybil attacks and bot farms.
"Every item is $6" is my general impression every time I do groceries.
Taxpayers have to pay estimated taxes ahead of time anyway, no? Lots of people are getting tax returns in April/May. So it's not like treasury can hope for some extra taxes *now*.
OB was waaay too early. Barely anyone was using Bitcoin then, and other than censorship resistance and novelty everything about using it for commerce was meh. DHTs have crappy UX (slow) and running your own things is a drag. On top of it there's just a standard bootstrapping problem: you need sellers to make buyers bother, but you need buyers to make sellers bother.
There are two answers to every technical issue:
* nixify it,
* or rewrite it in rust
https://www.youtube.com/watch?v=Q_wPGSfUEFY
Financial system in distress.
Hey, whatever works, works.
Though myself with built in fuzzy find and `fzf` well integrated with shell \\: https://github.com/PatrickF1/fzf.fish I have no problems dealing with large projects.
I have LSP hints displayed in my CLI text editor (Helix). I'm quite amazed. The experience got really close to VSCode, with all the benefits of CLI text editor preserved.
Bitcoin's consensus rules are held together by a network effect of individual incentives of its users.
Not a constitution, not the whitepaper, not the code, but each HODLer doing what best for them is what guarantees consensus rules enforcement.
The idea that a super-majority of Bitcoin users could get convinced that stuff like inscriptions introduces MEV, which undermines mining incentives and is thus breaking Bitcoin, and thus endangers the asset they hold dear is not a fantasy.
In such circumstances - not unlike UASF - Bitcoin users could enforce a SF that would kick out (e.g. make unspendable) certain outputs they deem undesireable. In essence it's a form of economic voting / war. Users that think that Bitcoin is best with the SF against users who think Bitcoin is best without it.
You might think it's not fair, etc. And maybe you are right. But if it was a super-majority and a SF would be successful, you would wake up on holding your inscriptions on a BCH-like minority fork and you can cry all you want about it.
Personally I think Inscription are really stupid, and they will fizzle out naturally, so no need to do anything about it. But just saying.
I've just got an upstream git version of helix installed on all my systems (because a PR greatly improving LSP auto-completion just landed) with handful of changes to my personal "nix" git repo by replacing nixos release version with a custom one, by substituting some lines and rustc compiler taken from nixos-unstable (next release).
Nix changes the way you think about Linux system building and what you consider possible.
Some databases have ways to block non-indexed queries. https://www.mongodb.com/docs/manual/reference/parameters/#param.notablescan
I generally think it's a mistake for SQL (and similar) to have a default query auto-planner. I would rather write something like 'take this index, filter for this, pick these fields, then join,..." - basically specifying the query plan myself. Too many times I got bitten by the planner using the wrong index. It's difficult to figure out & prevent, and sometimes query planner changes its mind for some runtime reasons (obviously always in production at 2am ).
https://github.com/rust-bitcoin/rust-bitcoin/discussions/1702
Someone published illegitimate bitcoin-internals crate, and has some litecoin related crates. Looks :sus: . Be warned, could be malicious.
Is it me, or did a lot of people I am following stopped posting on nostr and activity is going down?
CSS/HTML more important. I'm actually quite familiar with JS side. But anything is good!
I want to up my html/css game. I can glue together an UI with bootstrap, write dune custom css etc. but whenever I need some fancier layout and styling, it's a struggle.
Please recommend best learning materials for state of art web ui/css stuff.
https://news.ycombinator.com/item?id=34966137
🍿 Enjoying the screeching in the comments. :D
I would add: historically OOP movement did not make a good distinction between data and code. It's best when *data* is organized in a program like in a application-specific in-memory database (or just in a persistent database right away), while "objects" and interfaces are useful for *code*: https://dpc.pw/data-vs-code-aka-objects-oop-conflation-and-confusion
The biggest blunder in the Clean Code is the unconditional "prefer polymorphism over switch/if": https://dpc.pw/what-oop-gets-wrong-about-interfaces-and-polymorphism