Customize well-known

[potemkin_ai]

@murgero thanks! And yes, I'm aware of that nice web config

Once I found it I started immediately to think about what other fields I might need to add at well-known and be sure it won't be overwritten.

I guess some kind of custom entry record UI at Cloudron would be very nice there!

[girish]

@potemkin_ai said in Customize well-known:

I guess some kind of custom entry record UI at Cloudron would be very nice there!

These locations are known in advance / codified in RFCs and standards. So, while possible to have flexibility here , in most cases I think people just want an input box for enter some value. Are we missing some more well known entries here? Happy to add them to the UI.

[potemkin_ai]

@girish thank you!
Are they all described in the RFC? Couldn't it be some special app expecting some special values in there?

[girish]

@potemkin_ai that's my understanding. they are usually in specifications and not arbitrary.

[potemkin_ai]

@girish I believe I've seen this in some apps, including NextCloud at some release.

But let me just return back with some facts in my hands when/if I get something.

[potemkin_ai]

@girish , I've got one: https://github.com/vector-im/element-web/blob/develop/docs/e2ee.md

Is there any way you can offer custom strings in the well-known file?

[girish]

@potemkin_ai good find! Kinda bizzare why these settings are being put in well-known . Do you know the rationale? Why is this not in synapse's configuration ?

Regardless, we don't have a way to raw edit the well-known config (even though it's stored like that in the database). I guess we have to expose the raw well-known config ?

[girish]

I am thinking that maybe we should move the well-known config to the apps UI (away from Domains). The main disadvantage of this is that if you uninstall the app, the setting goes away. The advantage is that it makes people realize that an app is required at the bare domain to serve the well-known config.

[potemkin_ai]

@girish , thank you!

I don't know to be honest... I would rather put it in the client<->server protocol as well, especially since it's not something I would like to expose to everyone. Guess it's because of the mixed model Element took - they are targeting at wide communities as well as closed groups, which is kind of hard to mix.

Anyway, from what I remember (and I might be wrong) I've seen something at NextCloud as well, so placing it at the app level feels right.
The only reason why I would consider placing in a general location - it's to ease implementation, as it doesn't seem to be a very often used feature. And for it to work, I'm perfectly fine to go the console or whenever, just to make it work.

No harm - just a bit of trash - if it will remain after the app removed either.

[rmdes]

Here an example of how it could be interesting to be able to add a custom value
use case, self-verification in Nostr : https://wedistribute.org/2024/05/nostr-nip-05/

[JLX89]

Building on this, this would be a great feature and eliminate a lot of manual work. We typically place a security.txt file in each site, but the ability to just deploy this would be great and configure via the .well-known configuration.

I could be wrong, but could this be done at the "platform" level or would it have to be in each package?

For example, pretty easy in the WordPress Developer Package, where we just create the folder, drop the file, and add a .htaccess redirect for domain.tld/security.txt to domain.tld/.well-known/security.txt.