Cloudron Forum

We installed HPBE on a dedicated VPS and Nextcloud Talk is mostly ok for us now.

Simplex Chat is the best private messenger out there, that we have found. We'd love to run our own Simplex Server.

Another app we are keeping our eye on is White Noise, which uses the Marmot protocol.

@james

Using Bitwarden means keeping your secret on a potentially compromised device. Better to use a hardware key.

The problem with both Yubikey and Nitrokey is that if you lose the device, you lose the key. Big problem.

The fact you cannot recover a passkey, make those devices a pass, from us. Or at least, they must be used in a far more careful and limited fashion - ie, fallback to email recovery - than what would otherwise be the case (sovereign recovery).

With Trezor - and other hardware wallets that use deterministic webAuthN - you can recover from a seed. This means that the loss of a device is not catastrophic.

EDIT: Am reading the Trezor forums and apparently they do support Passkeys, it's just that the Resident Key is encrypted with the seed, and not deterministically generated. So for recovery, you just back up the file using regular cloud storage.

Looking forward to testing it on cloudron, and letting you all know the results.

https://trezor.io/guides/bonus-tools/what-is-fido2

so long as we can use an external signing device (like Trezor), and not trust some foreign spyware company like Google or Microsoft or Apple, that would be great.

@nebulon what about FIDO2 or WebAuthN?

BTCPayServer has now been updated to v2.3.3 (from 2.1.6)

Tested on our instance and it's running fine

https://git.cloudron.io/playground/btcpayserver/

We use desec.io

@robi for info, this is a non-pruned (full) node, as of today:

root@d1f00579-9662-4a14-896e-cf7cd8127709:/media/core# ls
banlist.json  bitcoind.pid  blocks  chainstate  debug.log  fee_estimates.dat  peers.dat  settings.json
root@d1f00579-9662-4a14-896e-cf7cd8127709:/media/core# du -sh
766G    .
root@d1f00579-9662-4a14-896e-cf7cd8127709:/media/core# 

@timconsidine when you say the config matches, you mean this part right?

# Bitcoin RPC Configuration
bitcoin:
  rpc_user: "bitcoin"
  rpc_password: "xxxxx"

Note that the rpc_password should be the actual password, NOT the rpcauth= value in the bitcoin.conf file (which is derived from the password)

@andreasdueren a good middle ground would be to make it easier for platform providers to install third party apps.

https://forum.cloudron.io/topic/14231/ccai-cloudron-custom-app-installer

We are packaging another nostr relay for cloudron, the repo is here: https://git.nostrdev.com/stuff/cloudron-orly

This relay includes an embedded neo4j database. This requires enabling some additional ports.

The first deploy seems to be working smoothly.

However the second aborts as follows:

user@ft:~/git/cloudron-orly$ cloudron install -l mleku.ft.hn --image git.nostrdev.com/stuff/cloudron-orly@sha256:4e1fae78b22ce572d07b1c566b97623d948c98935e3c3de06f4b3ddd2e0adf30 
Port NEO4J_BROWSER_PORT: 7473
Port BOLT_BROWSER_PORT: 7687
Failed to install app: 409 message: Conflicting tcp port 7473

It seems to be possible to deploy in spite of this error if removing the "defaultValue" from the "tcpPorts" config. But then the UI appears borked.

Is there any way to have the tcpPort assigned (to the first available port, perhaps inside of a range) during the initial deploy?

How to deploy multiple instances of an app, that uses additional ports, using the CLI?

Hi guys

The latest instance of core is in the playground: https://git.cloudron.io/playground/bitcoin (yes, it's a dependency for btcpay server)

It's true that the entire blockchain is always downloaded (consuming bandwidth) but you don't need more than your pruned size setting in terms of disk storage.

The package also contains instructions to allow you to set a volume, so that the blockchain is not part of your backups.

Happy to jump on a call to assist if needed

we use desec.io, they're great, just be warned that you might hit rate limits if migrating a large cloudron instance to a new IP

any reason you can't just run your Bitcoin node on your cloudron instance? it's prunable, which means it won't take loads of space.

The rpc user/ pass definitely needs to be in the bitcoin.conf, it also needs to be salted/hashed, see: https://github.com/jlopp/bitcoin-core-rpc-auth-generator

If you install bitcoin core, the btcpay server will automatically use your local (cloudron) instance

we didn't test the install against a remote server but your config looks good. Your IP is a regular IP right, not a domain?

  rpc_user: "bitcoin"
  rpc_password: "pass"
  rpc_host: "172.28.0.2"
  rpc_port: 8332
  node_endpoint: "172.28.0.2:8333"

The nbexplorer thing is internal to btcpay server (this was the hardest part about setting up the container)

Does your remote btc core instance have rpc enabled? something like this in your bitcoin.conf file:

rpcauth=bitcoin:pass

The problem is that fiat is constantly being debased / inflated, such that money spent today becomes worthless after a few years

Agreed that we should not use cloudflare, not just from the single-point-of-failure perspective, but also to protect user privacy

We would like to see a cloudron reseller who accepts Bitcoin for payment

It appears the turn server is no longer used as an addon in SFU - could this explain why the app just does not work for many of our participants for several months now?

https://git.cloudron.io/packages/mirotalksfu-app/-/commit/05013ccfb0cbd9342433783e8ffe7c3fb14fa600

done! we would like to add that the packaging team should prioritise the custom app installer over btcpay server (as we can easily deploy apps using the package installer from that point onward)