43 lines
1.8 KiB
Markdown
43 lines
1.8 KiB
Markdown
# Terminology & Vernacular
|
|
|
|
Instance
|
|
: Primarily for instance owners. One guild/group/_user server_ which
|
|
|
|
Server
|
|
: mainly used for users so that they don't have to worry about new terminology.
|
|
|
|
# Server(s)
|
|
|
|
Assuming instance/guild owners don't want to bother setting up their own thing: provide a mechanism where they can pay to spin up a VPS on their behalf; set up credentials but leave whatever happens on their VPS their problem, we just provide the service to quickly spin up and continue payments through the main site.
|
|
|
|
Owners are still free to host on their own instances on their own terms but user accounts won't be tracked on the mainline system.
|
|
|
|
Preservation configs:
|
|
|
|
* Expiry: (None/0/ 1-n): determines how many days a single _non-sticky_ post will last. (Max stickies is going to be hc'd because fug ppl that try to sticky everything(something like 100 or something idk
|
|
|
|
Temporary conservation of posts:
|
|
|
|
_Taking the image/text board approach_.
|
|
|
|
# Client
|
|
|
|
UI
|
|
: _tbh just make it look nice_
|
|
|
|
Accounts - this is where the bs gets messy
|
|
: Users can register under main line in which case they can join "any" server that let's them use a global account
|
|
: ^The default for servers is to allow global accounts into the thing
|
|
: USER ACCOUNT ID'S ALWAYS POOL FROM A MAINLINE BRANCH - you can turn this BUT you get no support from mainline clusters(i.e. not allowed to pool user accounts from mainline)
|
|
|
|
# Current Goals
|
|
|
|
## Server
|
|
|
|
For now it should provide some endpoints for each instance's websites.
|
|
Afterwards there should be some kind of textual endpoints for clients to send messages to various channels.
|
|
The server itself can take two routes for sending messages to lots of clients:
|
|
|
|
* Clients can repeatedly query the server
|
|
* Server can do some kind of broadcasting to each client
|