| Age | Commit message (Collapse) | Author |
|---|
|
This is needed as the transports are by default treated as guests by prosody,
and therefore unable to upload files without explicit permission.
|
|
The template worked fine for singleton lists, but it fails when adding another
entry since there is no separator between the elements! Thankfully Lua has some
nice syntax allowing you to use a semicolon as a separator, which doesn't by
itself imply more than one element.
|
|
This commit allows transport servers to define the relevant components on the
XMPP server. Transports are configured by adding the following config to the
inventory's variables:
transports:
- subdomain: a-example-legacy-network
secret: a-long-randomly-generated-secret
- subdomain: another-example-legacy-network
secret: another-long-randomly-generated-secret
These are iterated over and a privileged component is created for each.
|
|
If a section is not enabled on a particular server, that section's header
comment should not be visible.
|
|
This configuration allows me to remove the proxy DNS records, and keep the
configuration internal to prosody.
|
|
We do not need s2s modules or config for a single-user transport oriented
server.
Likewise, we do not need admin or abuse contacts if s2s is disabled. No
messages can escape, and it would be impossible to contact them regardless!
|
|
Use consistent 4-space indentation.
Do not allow new scopes to be opened and closed on the same line. This allows
me to more easily add jinja if statements without having to make formatting
changes at the same time.
|
|
There will be no s2s connections on the transport server, so anti-spam modules
won't provide much benefit.
|
|
Invites are not needed on a single-user transport-only server. Therefore, place
this functionality behind a flag.
|
|
I am planning on deploying a new single-user server, without s2s connections or
other features, specifically for transports.
This necessiates splitting off some functionality behind a flag, so that it is
only enabled for non-transport ("standard") servers.
|
|
While looking through the list of available prosody-modules, these
seemed useful.
|
|
While looking through the list of available prosody-modules, these two
seemed useful.
|
|
Thankfully the servers I manage have not seen any spam, nevertheless,
I'd rather set up some kind of mitigation now, before it becomes a
problem.
|
|
This is not available in prosody-modules
0.0~hg20250402.f315edc39f3d+dfsg-2.
|
|
There's no need to jump back to 2 GiB yet, but I was finding 10 MiB too
restrictive.
|
|
This was originally intended for motoristic, but is no longer needed by
any domain.
|
|
This was only ever enabled for testing purposes, and is no longer
needed.
|
|
I made a mistake in the original configuration - I tried to give each
virtual host a separate turnserver on its own subdomain. However, since
koyo.haus and fennell.dev (and likewise in nonprod) share a virtual
machine, they can only have one turnserver between them (in the
turnserver.conf, there can only be a single realm).
Therefore, always point to koyo.haus for the turnserver in each
environment.
|
|
|
|
This was quite generous, and if everyone used it at the same time, the
host would fall over!
|
|
|
|
This is useful for two reasons:
* To test clients that render roster groups provided by the server
* To evaluate whether it is worth enabling this flag in production
|
|
This is to test how clients handle downloading large files.
|
|
This is in order to debug an issue I was seeing with group chats previously. I
don't believe it actually had an impact, but I can't remember for sure now. I
should debug this at some point and remove if necessary.
|
|
This is so that I can test sending a relatively large APK in order to debug an
issue in Dino.
|
|
I am rolling out a Matrix bot that will auto-reply to contacts in bridged
conversations, encouraging people to reach out to me on XMPP.
The bot will send them an invite link, retrieved from this API.
|
|
This will primiarly be used for motoristic.
|
|
|
|
We remove some extra MUC configuration here that should not be needed, as these
settings should be handled by the defaults anyway.
|
|
I misunderstood how MAM works, and thought that storing messages long-term
would allow new clients to retrieve long-term history. This commit moves the
server's configuration back to the default of one week.
|
|
|
|
This commit adds support for XEPS 0065 and 0365 - i.e. sending files from one
account to another.
|
|
This commit uses the new per-host virtual_host variable to create the necessary
prosody host-specific cfg files.
|
