Skip to content

Proposed variable strings for self-hosting #5

@dgw

Description

@dgw

Following up on our lovely little fediverse conversation that spawned from my random ideas at sopel-irc/sopel#2599 :)

To make this service self-host friendly, I see a few strings that would be helpful if made configurable:

  • The domain name used in API examples and the "custom URL like this" instructional block
    • "Base URL" would be more flexible, but why enable hosting plain-HTTP services in 2024? https:// or bust!
  • The "From Within" footer text
    I don't suggest making this fully customizable, but rather one of the below options:
    • A Boolean toggle that changes it to "Built by Within" (or something like that)
    • A custom string that must contain a {source} placeholder* linking to the source code, Within, or whatever would be preferred as a "we got this software from here" credit — enabling a clear distinction between "we host this" and "they wrote this"
  • Who to contact in the error page message, currently hardcoded to please contact @cadey@pony.social for help
    It's probably preferable to have self-hosted instance owners handle error reports from their own users, and only forward them upstream if it's something this project might want to do something about.
    • Simplest option is to just accept an alternate Mastodon/fediverse user identifier
    • Slightly more complex option is to take two values, a URL (not constrained to http(s)) and display text
      For example, my project might want to send people to our IRC channel using an ircs:// link

As far as implementation goes, my idle (and noobish) thought is that it'd be simplest to allow configuring these via environment variables. If an envvar is missing/empty, the software would use the current values as defaults. Variables are easy to pass in as part of spinning up the container (docker run -e, .env file, environment compose file key, plenty more) and are, I think, preferable to creating some form of configuration file within the Docker container that has to be mounted/managed.

The only thing that could make the result any easier to use would be a publicly accessible container image published on some registry, whether ghcr.io or otherwise. (But that is a wholly separate topic that deserves its own issue if it needs discussing! nix build .#docker and a docker image tag command or two works just fine, especially if a Docker noob like me could figure it out in 5 minutes.)

Thanks again for building this and putting it out there! Functionally it's already 99% of the way to what we'd want to make. 😸


* — I'm a Rust noob, so I don't know what its placeholders look like. Consider this pseudocode!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions