On money, liquidity and eurodollar - or why stablecoins more often used as money comparing to bitcoin - against Austrian economics expectations - and in the future this doesn’t seem to change.
Imaging you run a factory producing metal chunks. Your supplier is an iron mine. A client who bought last consignment from you is late with the payment - but you still need to buy from the supplier to produce the next consignment.
Normally what you do is you go to the bank and take a loan - a credit against collateral of your factory assets (equity shares, goods and other forms of capital). However, during crisis fiat banks avoid high risk and do not provide credit - or ask interest rate which destroys your business model. That is why central bank system has emerged as a credit of last resort - but as we know it doesn’t work as expected.
In hyperbitcoinized world if you go to bitcoin hodlers (new form of bankers) - they would put even higher interest rate to match the bitcoin volatility risks. Thus, you can’t operate under such conditions.
Where are we left? A good factory with no real problems has cease to operate/stop ovens (which kills them) - why? Because there is no liquid money in form of credit available - and #Bitcoin doesn’t seem to be fixing that in any way (instead it will make the problem to be worse than in the gold standard age, since the gold can be mined - while bitcoin, after some period, is not).
So what market participants will do? First they will switch to barter (like in post-USSR in early 90-th), but because of its inefficiency soon they will invent their own credit liquid money - and, if it would happen today, it will be probably on form of crypto. This will be an IOU money. Eventually a new private banks will emerge which will be producing those money in return for collateral, doing risk scoring.
This is why I am after private banking school of economics - and not Austrian nonsense about economics being able to run with hard money made of scarcity. Money must be liquid.
This is the use case for crypto or digital finance - and the reason why stable coins gain such tracktion (before them it was eurodollar, which is in fact a private banking money not managed by central banks - a dominant form of money in the world as of today).
Look nostr:npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym seems someone already took advantage of the fact nostr uses schnorr to make multisig publishing. I haven't used it yet to know the shortcommings, but seems to be the right approach for community owned nostr accounts https://github.com/nickfarrow/frostr . We only need to make better management tools and probably integrate it to some clients, but if it all works as I think it will, no new NIP's are required.
After initial analysis I think this is an example of overengineering which doesn’t exactly covers use case needs - while simplier alternatives do.
What orgs need is:
1. “Genesis” key for the org held by current CEO or CMO;
2. Which creates dedicated even types (not usual posts) delegating org right to other keys (ppl in marketing team) - and revoking that delegation when a member of the marketing team is fired;
3. This “genesis”/control key may also be revoked in case of CEO/CMO change; and a new key is appointed.
Clients may present all events from all org-delegated key as a keys under the same “virtual” org account.
Look nostr:npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym seems someone already took advantage of the fact nostr uses schnorr to make multisig publishing. I haven't used it yet to know the shortcommings, but seems to be the right approach for community owned nostr accounts https://github.com/nickfarrow/frostr . We only need to make better management tools and probably integrate it to some clients, but if it all works as I think it will, no new NIP's are required.
Interesting, will check! For me the main problem of multisigs on nostr: they are needed for orgs, but they can’t serve orgs needs, since people in orgs are get fired and replaced, while the npub of the org must not change. This makes impossible any serious use case around multisigs in the current way they are set up (with Schnorr signatures and not in a GPG style).
I think #Bitcoin and #Crypto worlds do diverge.
I see the foundation of #Bitcoin to be censorship resistance, and, as a result, unconfiscatability and freedom of monetary transactions. Others see the core of it as digital scarcity building hard and sound money - a long-term store of value (the second requires the first; however the first can also exist even without the second).
I see #Crypto as a democratization of speculatory financial activities and gambling. Don’t get me wrong: I say that without a negative connotation, since I do believe both are important as a form of games. Children play games to develop their intelligence, adults play economic games and gamble with a skin in the game because of a similar reason: it is a way of competition and evolution of economical intelligent agents. If one day there would be an AI, it should start with a similar simulations. Another related goal of crypto is to make money which are not hard, but liquid money (becoming easy money as a result). Crypto talks a lot about decentralization, but in reality there is no real decentralization; they use an illusion of it as a way to distract regulators from attacking.
This difference explains why crypto people do not understand bitcoin - and why bitcoin is not interested in crypto. In fact, they do not have any intersection at all!
There is more to the equation: #cypherpunk, where Bitcoin has emerged, goes beyond what Bitocoin can do today, since it is more concerned about privacy than existence of hard and sound money (thus I do not consider projects like Monero or Grin to be crypto projects). However, Bitcoin still shares a lot with it, since real censorship-resistance and freedom of transactions is impossible w/o privacy - however the tradeoffs bitcoiners and cypherpunk are willing to pay are different (that’s why there is still no confidential transactions in Bitcoin, since absence of hidden inflation is more important for bitcoiners than privacy). BTW, #RGB is bridging this gap, but that’s another story.
Finally, there is a crypto-anarchism, which, for the first look is similar to cypherpunk - but in reality it is much closer to the crypto world than bitcoin. Crypto anarchists are not worried about the nature of money; their focus is privacy as means of breaking attribution and having _any_ form of financial activity to be non-attributable.
However, my own position touches all of these spheres (and to none of them in full): what I am looking for (and contribute in building) is private, uncensorable, unregulatable agoric finance still allowing voluntary disclosure. Decentralization here is not a fetish: it may still contain naturally-centralized parts (like asset issuers for shares or bonds), but in other cases decentralization may be necessary for maintaining censorship-resistance (like DEXes for the secondary markets of the shares). This is the vision we have in our Pandora Prime company building Pandora Network project, leveraging our developments in Bitcoin, Lightning and #RGB smart contracts made during past years as a part of LNP/BP Standards Association. 
#[0] have you looked at #[1] for chat/file transfers? Does storm do all it does and more or are there merits? Thank you! https://simplex.chat/blog/20230301-simplex-file-transfer-protocol.html
Not yet, will have a look. Thank you!
How #Storm ⛈️ differs from #Nost 🦩?
Several years ago LNP/BP Standards Association presented Storm protocol suite for decentralized storage and messaging. It operates on top of #LightningNetwork ⚡️ and provides a way of setting up long-term trustless storage channels, as well as an API for structured data propagation, storage and - last but not least - querying.
The first applications demonstrated in summer 2021 to work with Storm were file sharing 📂, chat 💬 and data transfer for client-side-validation #RGB smart contracting system 🔴🟢🔵
Storm provides functionality similar to #Torrent, #IPFS, more recent #Hyperdrive and other distributed data networks - but right next to Lightning channels, with linked Lightning payments and without use of DHTs.
In other words, #Storm may be seen as #Nostr “on steroids” where:
- relays are Lightning Nodes;
- not all data has to be signed, opening use case beyond social networks;
- embedded indexing and query capabilities allowing to build decentralized search engines (“decentralized Google”);
- support for trustless data storage based on zero knowledge with specially-designed form of Lightning Storm channels;
- data can be organized in application-based silos, and construct a DAG-based hierarchies;
- data are binary, may provide a custom application-specific schema for their internal structure.
Our recent #reNostr initiative uses the experience we have acquired while working on #Storm. It targets making #Nostr more scalable and robust, and will also provide an interoperability layer between #Storm and Nostr, such that Nostr data may be hosted by Lightning nodes via Storm protocol ☔️ 
“Prejudging” means “using reputation which you associate with identity”.
Yes, it is both good and bad
The moment when you realize that #Rust 🦀 crates you made were downloaded more than 2 000 000 times
It does not provide a deterministic encoding though
The moment unencrypted private key touches the memory - forget about safety. Even C and rust compilers create copies all around (and zeroize doesn’t help), what to say about python, go and other garbage-collector based languages…
Introducing #reNostr: the effort to built faster, more secure & scalable #nostr upgrade.
reNostr for Nostr is like SegWit for #Bitcoin
Join the work, which will be managed by Cyphernet - Swiss non-profit we are establishing with partners.
reNostr will provide a reliable binary protocol - new transport for #RGB client-side-validated offchain data - as well as medium for new contracts distribution and some of DEX operations. It will be also used in other wallet-related workflows by MyCitadel wallet.
Join the effort: https://github.com/renostr/nrps 
I read comments from different devs on my recent #nostr PR (the link at the end of the post) and I think I start to understand why underdesigned protocols get higher adoption than thoughtfully-designed.
Thise is not accidental; devs adopt protocols because they are able to understand them and play with them - and most of the devs (grown on stackexchange) have limited capacity to understand and contemplate about something (or just do not want to bother) - that is why “AI” is already able to make a work better than they do. That is why it is not the robustness or security which matters, but simplicity and as few components as possible.
It is the reason why crazy-weird combinations like “Web technology” - an agglomerate of highly-inefficient and insecure HTTP, JavaScript etc - boosted internet adoption, while it took decades to solve this protocol issues with additions like SSL/TLS, HTTP/2, ECMAScript 6, TypeScript etc “ugly sticked as siding”.
IT differs in these terms from other forms of engineering in a way that if in a physical world you would build something with this approach, it will kill people (like cars and electrical equipment can do that) - while in IT the risks are much lower (usually financial) and more tolerable, thus less advanced and secure systems emerge.
So, there are two different strategies in protocol creation and adoption, similar r- and K-strategy in biology ( https://en.wikipedia.org/wiki/R/K_selection_theory ):
* r-strategy: very few devs, careful thoughtful design, high quality
* K-strategy: no design, “evolution as it goes”, development by a crowd of low-quality devs, until eventually something will start working due to a pure “mining of chances”
r-strategy always struggles with adoption, since “very few can understand it”. The only way r-protocols can be adopted is via products, which must be robust and good in UI/UX; i.e. not via dev community/crowd, but via people community/crowd. But usually r-products are not loud in marketing (the only exception is probably apple products - with NeXSTEP-based tech and product/language design teams being very r-like)
On the opposite, with K-strategy, things like JSON happen because they allow not to design a protocol - they are sufficiently agile and malleable to any protocol changes and things will contrinue to “sort of working” - thus devs can start with a “no design” and stick random elements into the network until something would start working. 99% of these protocols will die, but out of 1000 attempts one nostr will appear.
So any carefully-thought solution to nostr design issues (which will cause its painful growth/scaling in the future) is doomed: nostr devs see these not as a design issues but as features that allow them to build products without designing the protocol per se, leveraging JSON agility. So they agree to migrate to binary formats _only_ if they are same flexible as JSON - while the main problem is not a text/binary format but that flexibility, which will cause network decoherence - or centralization around oligopoly of “standard” relays. The funny part is that this r-strategy still can be the strategy which wins.
Not US but Swiss: we did #TheFreeAI manifesto https://thefree.ai and Prometheus protocol for decentralizing ML https://github.com/Prometheus-WG/prometheus-spec/blob/master/prometheus.pdf
Backed 2017 by Pandora Foundation - a Swiss non-profit under article 60 of the civil code (something probably similar to 501c3s).
Never heard of holochain. I assume they require to buy some tocken? :)
Have found a definition for #nostr I am comfortable with:
Nostr is self- and shared-hosted trustless event logs.
(Nostr relay is a self- or shared-hosting thing)
It had started as a platform for social networking, but can be used for groupware and corp applications, cross-device app synchronization, attestation logs and many other things.
Lightning was supposed to solve on-chain congestion problem, not join it!
Routing nodes now have to reserve up to thousands of $ for fees: this is the way LN is designed today (example of how this might happen can be found in https://twitter.com/ln_capital/status/1656003985948516352?s=46&t=ipsBmXsnm96namW0IOz1Ig). It doesn’t mean this money are lost, but they have to be subtracted from the channel balance, increasing existing LN liquidity problems.
One of the strategies the nodes may follow will be to stop routing until good fees are back - and keep commitment transactions originating from the times when fees were low.
Current software doesn’t support this, but the future versions may do.
This will mean that with high onchain fees LN will degrade in performance and liquidity too.
I am working on a protocol which will combine both RPC and PubSub model (in mutexed way). It will work either as a binary TCP protocol - or can be bridged via combination of HTTP and WebSocket connection.