Why did eSIM previously rely on google services, but now it doesn't?

So the stock OS eSIM package is open source so there is also no reason to use anything else?

Generally I'm wondering if any eSIM tools in android can help with https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/485 .

Any idea how the CalyxOS eSIM support works compared to Graphene? CalyxOS doesn't seem to indicate much about what they are doing with eSIM.

Any idea why Graphene does not use https://gitea.angry.im/PeterCxy/OpenEUICC ?

With StaticWire you have all UDP and TCP ports.

I don't think tunnelsats is more simplicity because you have to run on non-standard ports. Tunnelsats should be cheaper for sure because they aren't allocating you as much capability with their service and you have to deal with the complexity of non-standard ports.

Yes, you can route all ports. You can use an RPC, accept incoming peer connections, run a btcpay server, etc., all on standard ports.

I'd try StaticWire over tunnel sats. StaticWire will give you a complete IP address all to yourself.

Would rather this not require an app, but would rather have a web interface. Don't want to have to install an app with a bunch of permissions in order to be able to rent a campsite.

As an EV driver, I would like to only pay for the parking spot, shower/toilet, and electric and not have to pay for water and sewer as I won't be using them, but at most campgrounds you have to pay for all if it together because most people use campers that want it all.

https://zerosync.org/ is cool, but I feel like that is part of a different level of the technology stack than where I am working at. If those other levels adopt it I will likely be on board incorporating it, bit it is not part of my core focus right now.

Definitely interested in using Distributed Charge technology for campgrounds. Although I'd like a dual metered trust-minimized micropayments based approach for energy and water delivery, I think that right now people are going to want to just make simple daily payments and leave some trust in the campground operator.

I'd be curious to know if the campground owners and customers are content with selling electrical energy at a fixed daily rate without metering or if they'd like some metering with periodic manual payments. Does anyone out there have an opinion on that?

I have a feeling that water is too cheap in most places that it won't make sense to include the metering system for it and just charge a fixed daily rate.

Will customers demand a partial refund for energy and water if they leave the campground early or will they be okay forfeiting that service? If so, I know of two ways that refunds can be done with lightning:

Which one of these would be preferred if they are necessary?

I have put something together called the Board A0 Relay Demonstrator. It can be used for doing simple switch control which doesn't require metering. I have not published much information on this, but in this workshop at TABconf I walk through using the hardware and creating a simple application from scratch that controls the switch : . The Board A0 Relay Demonstrator is sitting on the floor of the stage to the left of the me.

Take a look at https://github.com/AndySchroder/pyKeysend . There I started working to make a general purpose data transfer protocol that partitions the data based on the maximum amount and then reassembles it, but as you will see in my initial results, data transfer rate is very slow.

If you pair bitcoin mining with Distributed Charge - GRID (http://andyschroder.com/DistributedCharge/GRID/Overview/) and a lightning enabled mining pool payout, the miner can collect their revenue and pay for their expenses directly with lightning without needing to make extra on chain transactions. Mining pools can afford to make much more rapid payouts with off chain transactions. Making much faster payments for your expenses with Distributed Charge - GRID allows a miner to operate a bit leaner than they otherwise (they will collect revenue and pay their main expense nearly instantly) would and will allow them to take part in the future where we have a truly decentralized energy grid where instantaneous pricing is based on the price your neighbors are willing to buy and sell energy at right now.

I'd say that will be a big incentive to run a lightning node as a miner, but not necessarily an advantage over players in the marketplace. In a bitcoin only economy, everyone should be collecting their revenue and paying their expenses with lightning, but right now, miners can only collect their revenue in bitcoin, so the will be early adopters

Distributed Charge uses ubuntu server so it can run LND directly. Blixt look cool, but a major drawback is no reproducible F-droid build right now. Also, it's unclear where the push notifications are coming from. Why do we need push if the node is running locally on the phone?

I agree.

We also have "non custodial" which leads people to wonder how that is different than "self custodial".

Okay, maybe I'll re-post the survey another day with some more options to choose from. I was trying to figure out if people thought auto-signing systems like greenlight were actually self custodial. Seems so far that 27% of the people think so. I threw in voltage.cloud as another option to gauge the audience as well. Very surprised that 13% of the people think that is self custodial when they have your private keys in RAM. It seems as though not only do we have some interesting services like greenlight which push the limits of what you can call self custodial, but people may not really even know what the term self custodial actually means if they are okay with someone else holding their keys in RAM.

But how many people connect exclusively to nodes run by "well known bitcoiners, devs etc."?

Do you know how the Phoenix solution compares to Breeze wallet or Greenlight? Wondering if those should all be considered in the same category.

So what option should I have added for you to choose? What example can you provide that would be a weaker self custodial option in your opinion?

What is your definition of "the main bitcoin nodes"? According to https://bitnodes.io/dashboard/#asns , 1.8% are on AWS and 1.9% are on google. 63% are on TOR.

Also, you'd have to migrate to an alternate "something like greenlight", but with bitcoin nodes, you don't migrate anything, you just connect to a new peer and ask for data. I think that's a huge difference.

Seems like it would be more appropriate to decay with block height and not clock time... and also slow things down if the weather is nice :) .

So, which option did you vote for then with this perspective?