At present, Hollo does not have any database table that can hold key/value pairs for server configuration. For instance, this might be text for privacy policies or terms of service, or other data that can be configured by the admin.
The schema for this settings table could be:
CREATE TABLE settings (
id SERIAL PRIMARY KEY,
key character varying NOT NULL,
value text,
created_at timestamp without time zone,
updated_at timestamp without time zone
);
CREATE UNIQUE INDEX index_settings_on_key ON settings(key text_ops);
Where the value column stores a value that's a JSON string. (in Mastodon, they use yaml)
This allows us to store fairly arbitrary configuration as necessary. For instance, we may want to allow enabling/disabling a public accounts list, or enabling/disabling rss feeds, or other features.
Additionally, it would give us a place to retain environment variables which, if changed, could cause issues with federation (primarily STORAGE_URL_BASE, but in the future LOCAL_DOMAIN), storing these in the database would allow for us to show a notice to admins when a change is detected.
At present, Hollo does not have any database table that can hold key/value pairs for server configuration. For instance, this might be text for privacy policies or terms of service, or other data that can be configured by the admin.
The schema for this settings table could be:
Where the
valuecolumn stores a value that's a JSON string. (in Mastodon, they use yaml)This allows us to store fairly arbitrary configuration as necessary. For instance, we may want to allow enabling/disabling a public accounts list, or enabling/disabling rss feeds, or other features.
Additionally, it would give us a place to retain environment variables which, if changed, could cause issues with federation (primarily
STORAGE_URL_BASE, but in the futureLOCAL_DOMAIN), storing these in the database would allow for us to show a notice to admins when a change is detected.