You forgot the "refresh the video page multiple times and/or start/pause/unpause the video because google is making the youtube work really bad on non chrome browsers".
On their privacy terms:
However, for convenience, your Phoenix application delegates the calculation of payment routes to the ACINQ node. In the current version of the wallet, this node will know the final recipient of the payment, and the amount sent. Work is being done to remove that limitation and have better privacy.
So no privacy.
As far as I remember you don't have privacy with Pheonix, one channel with their node means they at least see liquidity going in and out.
I get your view point and it makes sense for an expert user, but you cannot realistically assume people will manage LN nodes and liquidity in their lives, there needs to be an alternative (not saying it is ark, or spark or cashu...) that is less custodial as possible, with good privacy and that you would be able to use by just opening a mobile app (no fancy liquidity management, just a secret/seed/key to backup and that's it). Otherwise the majority of people will just use "custiodial bitcoin banks". As much as I want LN to succede even further, I think the channel structure of the whole network does not scale really well, what I mean is this: the best would be for a thousands of small LN nodes (friends, family, small communities), but as much as we like it, we know that will never happen at full scale, so the other scenario is for fewer but bigger hub nodes, which is what is happening today and that I think will become (in my opinion) unfeasible to manage for a lot of users (think of acinq in an immaginary future with million of users, they will need to have massive funds locked up on channels, I am not sure this is economically viable in the long term). So just to say wee need alternatives and/or integrations with other systems.
What is the problem with Ark? I just want to understand your reasoning.
Yeah I see too few sepa/revolut orders now compared to months ago, all I see now is PIX and stablecoins. What do you europeans use now? Stablecoin wallets?
🚨 ANNOUNCEMENT: BULL Wallet is now available worldwide on iOS & Android!
A self-custodial, Bitcoin-only wallet designed for low-fee, private payments and long-term cold storage.
Built for cypherpunks. Perfect for beginners.
#Bitcoin, Lightning & Liquid: seamlessly swap between networks with non-custodial atomic swaps.
Open-source, privacy-focused, and beautifully simple.
Try it now: https://wallet.bullbitcoin.com/
Read the whole story by Francis Pouliot: https://www.bullbitcoin.com/blog/bull-by-bull-bitcoin
https://blossom.primal.net/e7c5313b8eaa8ae5c729d076d03d7431e8a86838ef65302368310ee8b5314339.mp4
How does the LN side work? How's the privacy level? Where can I read more info about it?
And when there are no cellular networks available or are taken down by governments/bombs?
I feel like these cases are a bit unexplored, but yeah mesh networks would be helpful to connect offline areas to other online areas. Really hope things like meshtastic, reticulum and lora can become more mainstream and be used in these scenarios. At least simple messages and transactions/tokens can be transmitted.
Exactly, and I am not even sure cashu can really help here, you still need connection to the mints once in a while right? Yeah offlin exchange is possible, but let's be honest, can you really go for months without internet? I am not sure.
Would be interesting to see development targeting exactly these scenarios, but I don't think this can ever be solve, first you need to better decentralize network infrastructure.
nostr:npub1lnvps32qq2nvg75cqwflq4y6cmnzn55d26ypzjakpkp3khqcx2ns7t7vjj Hi, is the IRE infra still under attack? I am basically unable to connect to the VPS in the last few days/week.
About the new regions mentioned in the customer support messages, will there be a way to migrate VMs if one want to switch?
Thank you.
We have early access to Android Security Bulletin patches and will be able to set up a workflow where we can have releases already built and tested prior to the embargo ending. For now, we've still been doing the builds after the embargo ends. It will mainly help when they screw up pushing to AOSP.
We're in the process of obtaining early access to the major quarterly and yearly releases. This is a much bigger deal and will substantially help us. There's an immense workload with a lot of time pressure for porting to new major releases without early access which gets worse the more we change.
We did not have early access to Android 16 QPR1 and have not been able to start porting yet. We should have early access prior to Android 16 QPR2.
We're going to need to make private repositories for working on this stuff internally. We can potentially make special preview releases based on these.
Google recently made incredibly misguided changes to Android security updates. Android security patches are almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
We can't break the embargo ourselves but if someone posted the patches publicly we would be able to ship them months early, as would others. The patches are broadly distributed to OEMs where most of their engineers have access. Companies like NSO can easily obtain access. It's not a safe system.
Google's existing system for distributing security patches to OEMs was already incredibly problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins. This is harming Android security to make OEMs look better by lowering the bar.
The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days. Moving in the opposite direction with 4 months of early access is extraordinarily irresponsible. Google has also abandoned pretending it's private by allowing binary-only embargo breaches.
Android's management has clearly overruled the concerns of their security team and chosen to significantly harm Android security for marketing reasons. Lowering the bar for OEMs to pretend things are fine while reducing security for everyone is a ridiculous approach and should be quickly reversed.
Android is very understaffed due to layoffs/buyouts and insufficient hiring. This is impacting Linux kernel and Android security. Google hasn't fixed http://taptrap.click which is a serious issue privately disclosed to them in October 2024. We were informed in June 2025 and it took us a few hours to fix...
Google does a massive portion of the security work on the Linux kernel, LLVM and other projects including implementing exploit protections, bug finding tools and doing fuzzing. They're providing the resources and infrastructure for Linux kernel LTS releases. Others aren't stepping up to the plate.
We don't expect there to be much pushback against this via tech media despite how obscene it is to provide 4 months of patch access to sophisticated attackers. They can easily get it from OEMs or even make an OEM. Whistleblowers should publicly post the signed zips since attackers have it already.
Security patch backports were pushed to the Android Open Source Project on September 2nd but it wasn't done properly. Android 16 QPR1 was also supposed to be pushed to the AOSP on September 3rd and it was even confirmed they'd still be doing that but it hasn't happened. Perhaps too many layoffs...
Even if no whistleblowers leak the signed zips we can still bring this system down ourselves without breaking any embargo. Our plan is to make special releases with the patches which are otherwise identical to our regular releases. External developers can reverse it from that for regular GrapheneOS.
We're allowed to make a release with currently available revision of the December 2025 Android security patches right now but we wouldn't be allowed to publish sources. Therefore, we'd need to do this separately from regular GrapheneOS. We could special release channels for it with delayed tags...
The purpose of this approach is for someone to reverse the Java and Kotlin patches to source code within an hour of us releasing that. They could then submit security patches elsewhere including to GrapheneOS that is open source. This clearly isn't something Google's technical security people came up with as it's completety nonsensical.
They clearly want to make life harder for anyone else, even security wise: "want to be "secured"? Use our google official phones!!! Oh you don't want that?! It would be really bad if this exploit only we know about would be leaked on the dark web, wouldn't it?
Ok, thank you for the explenation.
nostr:npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5 Is there a "discrepancy" between the latest google android 16 and the grapheneos one currently available for pixels? I was wondering mainly for two things:
- android desktop mode: is it currently available on your releases?
- new shapes and animation on top panel bubbles and items: am I wrong or does the latest android 16 grapheneos release still have the same "old" android 15 look?
I am asking as I don't know whether these things should already be present and I miss something or if the will be added on future grapheneos versions (because of all the shenanigangs of google lately).
Yeah I know, but you also need to be real, not everyone has the same opportunities and maybe live in different jurisdictions and sometimes stacking sats is the only/best thing one can do. So yeah I was wondering what are the options.
It seems to me recently there is a huge lack of #robosats orders accepting Revolut and SEPA compared to a few months ago. While I see a lot more USDTs and USDCs.
This got me thinking: it could actually be a good idea to use a stablecoins wallet just as a cache to buy sats on robosats, I mean, it is still better than full FIAT platform right? Right?
What would you say nostr:npub1lxktpvp5cnq3wl5ctu2x88e30mc0ahh8v47qvzc5dmneqqjrzlkqpm5xlc ? Do you have an idea on this? Are there good options?
Yeah you make valid points and I basically have the same concerns.
I don't really like the "let's go with linux native on mobile", but also the "let's fork android" seems limited.
Yeah it's all about how you configure the system (for example a lot of linux distros are insecure by default, how many of them have secure boot support, selinux/apparmor, ACLs out of the box?), but still the base was not designed with security in mind years ago, so the best would always be to design something new (just think about xorg vs wayland), but it's a huge task and really difficult to have something like that be developed in a complete foss manner (I mean in the linux spece there is red hat that is mainly pushing new security standards, selinux and the likes), I am not saying those are the best, but still they are something, but it all feels like a patch on top of something with a lot of holes 😅.
But yeah, android on top of linux could be better than native linux apps, bur at what cost? Batter, performance... It's a difficult world.
I know privacy is the ultimate goal, but without security, there is no privacy.
The problem is that linux on mobile has shitty security, while android (even better on grapheneos) and ios are really secure devices, which needs to be a priority on the mobile space.
It's just a downside of using a more native linux os, it's very difficult to have proper containerization, verified boot and all those neat features that we can have with grapheneos (which is why they only support pixel devices by the way)
Actually, sometimes I am able to start a chat with a contact setup using whitenoise (but unable to actually send messages) and some other times I cannot even start a chat, but probably the cause is some shenanigans with key packages and relays.
Yeah I know everything here is a beta, but wanted to be sure whether this was not intended/possible or just not ready/implemented yet.
Yeah then I saw w's message which was the same problem as I was facing.