Cloudron Forum

It's still down ... The registry itself is still up, so we decided to check the images against the registry instead to keep the updates going.

@MostlyHarmless welcome onboard! Just to double check , you are referring to the email from your Cloudron dashboard at my.domain.com, right ? (i.e not some email from cloudron.io) . Cloudron is entirely selfhosted. So, for my.domain , email is sent from your server (and not via our servers). It's quite common that your VPS provider blocks this. First step, is to check email status - https://docs.cloudron.io/email/#server-status . Is it all green? Are you able to send a test email via https://docs.cloudron.io/email/#send-test-email ? Check the mail server event log - https://docs.cloudron.io/email/#event-log

There is indeed no documentation for the schema as such Mainly the ldap server is tailored for the apps which authenticate against it and the attributes are not configurable. Due to lack of documentation, the only way to figure out the responses is by looking at the code, which may or may not help. The resonse attributes for a search query is essentially at https://git.cloudron.io/platform/box/-/blob/master/src/ldapserver.js?ref_type=heads#L166 while the supported DNs (which are also hardcoded) can be found at https://git.cloudron.io/platform/box/-/blob/master/src/ldapserver.js?ref_type=heads#L646 following.

Hello @charlesnw Thanks for the clarification.

I have merged the topics.

Phew, that was a wild ride! Major update and refactor of the Agate+ app completed. Updates pushed to https://git.cloudron.io/timconsidine/cloudron-agate-plus WHAT CHANGED : overcame significant routing challenges arising from combination of (a) gemini clients only work on port 1965 unless you specify the port in the address (gem.domain1.tld:19xx), and (b) Cloudron does not support hostname (SNI) checking for a tcpPort multiple instances of Agate+ can now be deployed (e.g. gem.domain1.tld, diamond.domain1.tld, ruby.domain2.tld) and work fully (famous last words ) certificate creation majorly simplified CHALLENGES the original Agate app supports virtual hosts, so why take a different approach ? Because in that case Cloudron features of managing users access to apps and their content would be compromised ( user would get access to all sites in the virtual host) gemini clients (Lagrange, Deedum, Amfora) will ONLY connect to port 1965 unless you put the port in the address (gem.domain1.tld:1966). I think this is cumbersome and unacceptable for daily usage. Cloudron does not currently support hostname/SNI checking of traffic on a tcpPort, just sends all to port 1965, because that's what the client instructed. But without the hostname check, gemini client requests go to the wrong instance. SOLUTION A little bit "creative". Agate+ provides its own proxy in the app the first "master" deployment on port 1965 not only serves out content to clients for its own domain (gem.domain1.tld), but also runs the proxy so, when a client makes a non-port-specified request to ruby.domain2.tld and Cloudron sends this to 1965 because that's what the client said to do, the proxy fetches the correct content from ruby.domain2.tld (running on e.g. port 1966) and returns it to the client, even though the user didn't specify 1966 in the address and the client did not request it from 1966. Cool, hey? additional deployments of Agate+ recognise that they are not the first Agate+ (i.e. not running on port 1965) and function as pure gemini servers (in fact, proxy features actually removed automatically on deployment) there is a small setup step for additional deployments, but I think I have made this really easy : see POSTINSTALL.md Is this complex ? Yes. No. Well, a little, but not really, unless you really want to deep dive into it. Otherwise just follow the instructions. Is this essential ? Yes. Gemini servers simply cannot function on a single Cloudron instance (common IP address) without some form of reverse proxy because Gemini clients will ONLY send to port 1965 if no port is put in the address. And Cloudron does not yet support hostname/SNI routing of tcpPort (only nginx https traffic supports hostname routing). I think this is the neatest solution to a potentially incompatible set of operating conditions (gemini client behaviour, lack of Cloudron support for hostname tcpPort routing). I will be testing more, but you can never have enough testing, so feedback much appreciated. Agate/gemini protocol has got me excited about potential uses, hopefully it can help others too.

Thank you @James In the interim, I am attempting a workaround <can't find fingers-crossed emoji>

@jdaviescoates said in Best privacy chat apps: VC mentality? Signal is a non-profit. No hard feelings. When something is backed by the wealth of a top 100 US fortune then saying that it's a non-profit is like playing the violin to me. I don't doubt that it is a non-profit but it just sounds like branding or and opportunistic decision. Maybe I'm just sceptical. VC and philanthropy go hand in hand but it's a societal model that I don't endorse. One can of course focus on the tech and its promises. Then Signal clearly stands out compared to other products. But like the point about encryption, I disassociate "best" and "privacy" a little (topic title). I absolutely belive that no useful Signal data can be retrieved from the AWS and Azure server, but nevertheless every user indirectly funnels money to these two unethical (at minima) corporations. Once it's sufficiently private (a fundamental right), let's look at the broader picture as well. I see tech is a cultural product and the adjective "best" can be used in a holistic sense. Just wanted to give a heads up for Threema in that regard. Move slow and fix things ️