Ordinarily accounts data is stored within a subdirectory of the application directory. This can also be changed using the **accounts-dir** option, which may be used together with other options as needed:
You can also leave out the **--password** option and then enter it manually, which has the advantage of passwords not being logged within command history.
Setting avatar or changing background is the same as for any other account on the system. You can also moderate a group, applying filters, blocks or a perimeter, in the same way as for other accounts.
By default the server will federate with any others, but there may be cases where you want to limit this down to a defined set of servers within an organization.
You can specify the domains which can federate with your server with the *--federate* option.
The **--posts** option applies for any ActivityPub compatible fediverse account with visible public posts. You can also use an authenticated version to obtain the paginated JSON for your inbox, outbox, direct messages, etc.
Deletion of posts in a federated system is not always reliable. Some instances may not implement deletion, and this may be because of the possibility of spurious deletes being sent by an adversary to cause trouble.
By default federated deletions are not permitted because of the potential for misuse. If you wish to enable it then set the option **--allowdeletion**.
Another complication of federated deletion is that the followers collection may change between the time when a post was created and the time it was deleted, leaving some stranded copies.
As a general rule, all posts will be retained unless otherwise specified. However, on systems with finite and small disk storage running out of space is a show-stopping catastrophe and so clearing down old posts is highly advisable. You can achieve this using the archive commandline option, and optionally also with a cron job.
Which will move old posts to the given directory and delete any expired posts. You can also specify the number of weeks after which images will be archived, and the maximum number of posts within in/outboxes.
Whether you are using the **--federate** option to define a set of allowed instances or not, you may want to block particular accounts even inside of the perimeter. To block an account:
Blocking based upon the content of a message containing certain words or phrases is relatively crude and not always effective, but can help to reduce unwanted communications.
To add a word or phrase to be filtered out:
``` bash
python3 epicyon.py --nickname yournick --domain yourdomain --filter "this is a filtered phrase"
```
It can also be removed with:
``` bash
python3 epicyon.py --nickname yournick --domain yourdomain --unfilter "this is a filtered phrase"
```
Like blocking, filters are per account and so different accounts on a server can have differing filter policies.
You can also combine words or phrases with "+", such that they can be present in different parts of the message:
``` bash
python3 epicyon.py --nickname yournick --domain yourdomain --filter "blockedword+some other phrase"
```
## Applying quotas
A common adversarial situation is that a hostile server tries to flood your shared inbox with posts in order to try to overload your system. To mitigate this it's possible to add quotas for the maximum number of received messages per domain per day and per account per day.
If you're running the server it would look like this:
With these settings you're going to be receiving no more than 200 messages for any given account within a day.
## Assigning skills
To help create organizations you can assign some skills to your account. Note that you can only assign skills to yourself and not to other people. The command is:
This extends the ActivityPub client-to-server protocol to include an activity called *Availability*. "Status" was avoided because of the possibility of confusion with other things. The JSON looks like:
This system includes a feature for bartering or gifting (i.e. common resource pooling or exchange without money), based upon the earlier Sharings plugin made by the Las Indias group which existed within GNU Social. It's intended to operate at the municipal level, sharing physical objects with people in your local vicinity. For example, sharing gardening tools on a street or a 3D printer between maker-spaces.
The calendar for each account can be accessed via CalDav (RFC4791). This makes it easy to integrate the social calendar into other applications. For example, to obtain events for a month:
You will be prompted for your login password, or you can use the **--password** option. You can also use the **--day** option to obtain events for a particular day.
Having search engines index social media posts is not usually considered appropriate, since even if "public" they may contain personally identifiable information. If you are running a news instance then web crawlers will be permitted by the system, but otherwise by default they will be blocked.
If you want to allow specific web crawlers then when running the daemon (typically with systemd) you can use the **crawlersAllowed** option. It can take a list of bot names, separated by commas. For example:
```bash
--crawlersAllowed "googlebot, apple"
```
Typically web crawlers have names ending in "bot", but partial names can also be used.
When attaching an image to a new post it is possible to have a watermark image stamped onto it. This helps to mess with generative "AI" scrapers, using images improperly without permission, attribution or financial compensation.
The watermark image can be set via editing your profile and then going to the **background images** section. Once that is set you can also use daemon options as follows to determine how the watermark is displayed.
```bash
--watermarkWidthPercent 30 --watermarkPosition east --watermarkOpacity 10
```
The opacity is a percentage value, and you could potentially use 100% opacity together with a watermark which has a transparent background.
The watermark position is a compass direction: north, south, east, west, or combinations thereof.
Even if the scraper bot tries to remove your watermark from the image by filling in from the surrounding pixels, the removal itself may leave a detectable trace indicative of improper use.
