This repelled me from IPhone for the foreseeable future: https://m.youtube.com/watch?v=nQ9LR8homt4

It's probably not even better privacywise than a well setup Google android. Came across this on Nostr, can't recall who I should credit.

Hey nostr:npub1phhmun8stkdvlmwkrw2zre7tddepvk6wvaycgqeqwddz04r7z3rslefkvq, had jij Cashu al ontdekt? Chaumian ecash te funden via lightning, maar t.o.v Lightning meer privaat en een bearer asset, dus vereist niet altijd online zijn om te betalen of ontvangen, alleen een veilige verbinding naar de ontvanger. Zie Cashu.space voor betere info, ik doe het ongetwijfeld ergens onrecht aan. Zou dit een missing link of extra link voor V4V en streaming sats kunnen worden?

Ik had je zo ecash moeten kunnen sturen vanaf Nostr naar Mastodon, maar daar is het nog iets teveel beta voor. Er is al via HAM radio cashu gestuurd dus podcasts kunnen niet achterblijven. (Dat doet podcasting ook niet, weet ik, bedankt voor je werk hieraan en doorontwikkelen daaraan!)

Makes sense yeah.

It also seems possible to get even cities to be fit for 'nice' strategies by being very hard on 'mean' exploiters but that seems like setting up for inevitable failure later on when meanies get reintroduced or some nicies get mean. Forcing other strategies is maybe just not durable

Very Interesting, thank you! I'm wondering how it would turn out in an environment where you don't get to recover from a loss or when every interaction moves on to another opponent. Cause that's possibly the case in real life, and tit for tat still feels exploitable.

Thanks, this was the error, had it when trying to zap npb1phhmun8stkdvlmwkrw2zre7tddepvk6wvaycgqeqwddz04r7z3rslefkvq

Really like it! If i nut towards a contact, where can they find the nut, in their DM? Also: tried nutting towards mostr-bridged contact, and this results in JSON error, is that expected behaviour?

Vergat daar nog aan toe te voegen: bedankt voor al je (nog steeds) baanbrekende werk voor podcasting, ben groot fan. Heb je op onverantwoordelijke wijze wat V4V gestuurd.

nostr:nevent1qqsyxqm23zlhvzhk4dvzu6wp5ge2u669n45wfdklewjdshxjsvur9zcpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qgs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccrqsqqqqqp7dhjgy

Hey nostr:npub13ql75nq8rldygpkjke47y893akh5tglqtqzs6cspancaxktthsusvfqcg7, had jij Cashu al ontdekt? Chaumian ecash te funden via lightning, maar t.o.v Lightning meer privaat en een bearer asset, dus vereist niet altijd online zijn om te betalen of ontvangen, alleen een veilige verbinding naar de ontvanger. Zie Cashu.space voor betere info, ik doe het ongetwijfeld ergens onrecht aan. Zou dit een missing link of extra link voor V4V en streaming sats kunnen worden?

Dit is vanaf nu een deel-scooter

nostr:nevent1qqsghhzrchf0w2w48dxdpalvkvu6gt7yy3uv5jmdgkq2454svr6praqpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqzyzrgt6l0vefn3htfx83veheur8vlpedpqe7frrezuuypcf2clra0sqcyqqqqqqgg2mjw5

If you don't agree, you probably are ineligible anyway.

Is the nukening still ging on?

Visionary!

Used to have buggy experience, mainly because of learning Lightning and self-owned node limitations. Had problems with:

-no payment routes (because of lack of channels to/from my node)

-too little liquidity, only small payments succeeded(because my channels were too small)

-bad connectivity when paying(because of congestion on Tor-network used to connect to node)

Have learned to fix those things, so they aren't much of a problem now. When you go custodial like ZBD, wallet of satoshi, ln.tips or the late LNTXbot on telegram, points above aren't your problem unless you pay an amateur Lightningnode like mine.

Lightings 'flaws' IMO:

-Ultimately limited by base layer, it only scales base layer a factor. High fees there means high costs in Lightning maintenance of channels

-Lighting nodes need to be on and reachable at all times for payments, this doesn't suit hardware used for Lighting like phones or Raspberry PiS (although there is lots of innovation and improvement done in this area)

-it's end form is still unclear and widespread adoption is still lagging. It could turn into a (corporate )settlement layer for payments between entities like ZBD and PayPal, or a pleb 2 pleb network of communities like El Salvadors BitcoinBeach and (Dutch) Satoshi Radio. Either way its still quite small communities and only a handful of companies that have yet adopted it.

What is currently the best way to set up an organisation's account on Nostr, just generate a nsec and a npub?

or is there some tool already or some hierarchical magic possible where you can link/put an organisation npub on top of one or multiple npubs (or below, depending how you look at it)

Just looking to mess around, I'm only an official representative of myself, not any organisation.

Can't say from the photo, and I'm guessing you disconnected it completely, but it often is to do with a diminished / too small throughput area for the current.

Lots of possible causes, Can be caused by a loose connection, which only barely connects and causes temperatures to rise, can be caused by earlier blackening which raises resistance for the black part and worsens this way. Could also be some loose soldering in the print.

Eens dat dynamisch niet voor iedereen is, en dat leveranciers de hedgers/buffer zijn tussen reële kosten en betaaltarief. Geen idee of de lasten van de netbeheerder wel/niet bij van de Bron terechtkomen, maar disbalans van het netis wel iets waar zeker kosten en problemen vandaan komen, dus dat moet ergens opgelost worden. Een marktoplossing daarvoor zie ik meer in dan een overheidsregeling zoals eensubsidie of accijns.

Ik denk wel dat met een net waarin een groot deel zowel afnemer als aanbieder kan zijn er veel meer buffers en stabilisatoren nodig zijn. Alleen leveranciers dat laten regelen is niet haalbaar, niet met de huidige vaste tariefafspraken. Zeker aanbieden moet IMO een terugkoppeling hebben naar de vraag die er op dat moment is, verplicht dynamisch of ontzettend veel voordeliger om dat dynamisch te maken zou een oplossing kunnen zijn.

Ik verwacht sowieso dat meer leveranciers dit gaan implementeren.

Zonne- en windenergie zijn volledig vraag-onafhankelijk volatiel energieaanbod, bij parken is er nog een centraal aanstuurpunt waarmee goed afspraken te maken zijn over wanneer er elektriciteit wordt aangeboden, dat is bij consumenten moeilijker. Alle toegevoegde zon en wind zorgt voor mogelijkheid tot grotere disbalans, dus dat vereist extra grote inspanning van de netbeheerder om te compenseren, mitigeren en dus ook extra kosten. Die kosten komen ergens terecht, meestlogische is om dit bij de veroorzaker van de disbalans te leggen, dus bijv. degene met zonnepanelen.

Om de kosten van netbeheer beheersbaar te houden moeten er sowieso prikkels komen om zon- en windenergie aanbod op marktvraag af te stemmen. Prijsprikkels zijn waarschijnlijk een vrij effectieve manier om dit aanbod vanuit consumenten beter af te stemmen op de markt. Huidige voorstel zal hooguit aanmoedigen om opgewekte stroom in eerste instantie zelf te gebruiken, niet per se de opwekker relateren aan de marktvraag maar het is wel een stap in die richting.

Eigenlijk denk ik dat uiteindelihk alle verbruikers en aanbieders naar een vorm van dynamisch contract moeten om de energieaanbod-markt in de buurt van efficiënt en werkzaam te houden.

nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg

If it isn't faith in humanity, something else might still be redeemed