125 lines
3.9 KiB
Plaintext
125 lines
3.9 KiB
Plaintext
|
|
Instructions for running of the honk.
|
|
|
|
-- posting
|
|
|
|
Should work as expected.
|
|
|
|
Limited markdown support:
|
|
**bold** and *italics*
|
|
`code` and ```code block```
|
|
> quote
|
|
|
|
Large images are rescaled and reduced.
|
|
|
|
-- sensitive honks
|
|
|
|
A honk that begins with the danger zone indication, DZ:, will be marked
|
|
sensitive, using the first line as a summary (spoiler text).
|
|
|
|
Alternatively, a spicy honk that begins with three or more peppers (U+1F336)
|
|
will be marked sensitive as well, with a subject line consisting of peppers.
|
|
|
|
-- following
|
|
|
|
In order to follow somebody, you need to enter one of two identifiers.
|
|
|
|
The easiest is probably their handle, the thing that resembles an email.
|
|
@name@example.com for example.
|
|
|
|
Alternatively, one may directly enter the actor ID, which is a URL that looks
|
|
like https://example.com/users/name.
|
|
|
|
Followed honkers may be assigned to combos, listing all their honks together.
|
|
|
|
Followed honkers will appear on the main feedtube unless silenced. Honkers may
|
|
be silenced by adding them to a combo named "-". (One dash.)
|
|
|
|
Selecting just peeping won't actually follow them. (Incomplete feature.)
|
|
Can be useful for managing as part of a combo, however.
|
|
|
|
-- xzone
|
|
|
|
Individual honks may be manually fetched via the xzone.
|
|
|
|
Additionally, entering a honker will fetch all their recent honks.
|
|
|
|
A list of recently known honkers will appear as well.
|
|
|
|
-- zonking
|
|
|
|
You can zonk anything you like (or dislike), either your own honk or
|
|
those of others that you're tired of seeing. Be advised that deletion
|
|
works poorly in a federated environment. It's more like please disregard.
|
|
|
|
The zonkzone supports muting unwanted contacts. One may mute an actor
|
|
(zonker), a domain (zurl), thread (zonvoy), or word (zword).
|
|
|
|
-- privacy
|
|
|
|
Posted honks are public. Welcome to the internet.
|
|
|
|
Received messages are only visible when logged in, regardless of addressing.
|
|
Content from outside is not publicly rehosted, unless bonked.
|
|
|
|
Received messages that are less than public are tagged with a red border.
|
|
As a special exception to the public honking rule, replies to limited messages
|
|
will be restricted as much as possible. Note that ActivityPub leaks. Do
|
|
not use honk for posting truly private information.
|
|
|
|
-- css
|
|
|
|
Custom CSS may be provided by creating a views/local.css file.
|
|
|
|
-- message
|
|
|
|
A custom server message may be set adding a ('servermsg', 'message') entry to
|
|
the config table using sqlite3.
|
|
|
|
-- emus
|
|
|
|
Custom emus may be provided by creating and populating the emus directory.
|
|
emus may be referenced when composing a honk via colon wrapping. How pleasant.
|
|
This :example: will be replaced by emus/example.png.
|
|
|
|
-- memes
|
|
|
|
To save disk space and avoid repeated uploads, the memes directory may be
|
|
prepopulated with bandwidth wasting reactions and referenced by meme: filename.
|
|
Example: "Woah. meme: woahface.mp4"
|
|
|
|
-- hoots
|
|
|
|
Link and inline a hoot from that other bird site.
|
|
hoot: https://twitter.com/tedunangst/status/839169710675611658
|
|
|
|
-- cleanup
|
|
|
|
One should occasionally run `honk cleanup` to free up internal space in the
|
|
database. This deletes honks older than 30 days, but not those posted by a
|
|
user.
|
|
|
|
One may also run `honk reduce [honker]` to delete honks older than 3 days.
|
|
This is useful to reduce the space requirements from following image bots.
|
|
|
|
(Neither command runs vacuum, so the file size will not immediately shrink.)
|
|
|
|
-- add user
|
|
|
|
Running `honk adduser` can add additional users. This is discouraged.
|
|
|
|
-- proxy
|
|
|
|
honk requires a TLS terminating reverse proxy be configured. It communicates
|
|
with other servers via https URLs.
|
|
|
|
If the proxy is configured to support caching, be mindful of the fact that
|
|
ActivityPub requests vary based on the Accept and Content-Type headers.
|
|
|
|
ActivityPub in practice uses HTTP signatures to verify requests. In order for
|
|
this to work, the backend server must receive certain header fields
|
|
unmodified. In particular, the Host header and the message content cannot be
|
|
altered.
|
|
|
|
Specifically, for nginx: `proxy_set_header Host $http_host;`
|