2019-08-29 11:16:33 +00:00
# Epicyon Project Goals
* A minimal ActivityPub server, comparable to an email MTA
2021-01-24 13:34:48 +00:00
* "Small Tech" ethos. Not many accounts per instance
2021-01-24 13:11:37 +00:00
* Centering people and personal computing, not corporate or organizational accounts abstracting people away
2019-08-29 11:16:33 +00:00
* AGPLv3+
* Server-to-server and client-to-server protocols supported
* Implemented in a common language (Python 3)
2021-01-24 13:34:48 +00:00
* Keyword filtering
2021-01-24 13:21:50 +00:00
* Attention to accessibility and should be usable in lynx with a screen reader
2019-08-29 11:16:33 +00:00
* Remove metadata from attached images, avatars and backgrounds
2021-01-24 13:21:50 +00:00
* Support for multiple themes, with ability to create custom themes
2021-03-16 21:52:03 +00:00
* Being able to build crowd-sourced organizations with roles and skills
2019-08-29 11:16:33 +00:00
* Sharings collection, similar to the gnusocial sharings plugin
* Quotas for received posts per day, per domain and per account
2021-03-16 21:52:03 +00:00
* Hell-thread detection and removal
2019-08-29 11:16:33 +00:00
* Instance and account level federation lists
* Support content warnings, reporting and blocking
* http signatures and basic auth
2021-03-16 21:52:03 +00:00
* JSON-LD signatures on outgoing posts, optional on incoming
* Compatible with HTTP (onion addresses, i2p), HTTPS and hypercore
2021-01-24 13:34:48 +00:00
* Minimal dependencies
2021-01-24 13:11:37 +00:00
* Dependencies are maintained Debian packages
2019-08-29 11:16:33 +00:00
* Data minimization principle. Configurable post expiry time
* Likes and repeats only visible to authorized viewers
2021-03-16 21:52:03 +00:00
* Reply Guy mitigation - maximum replies per post or posts per day
2019-08-29 11:16:33 +00:00
* Ability to delete or hide specific conversation threads
2021-03-16 21:52:03 +00:00
* Command-line interface
2019-08-29 11:16:33 +00:00
* Simple web interface
* Designed for intermittent connectivity. Assume network disruptions
* Limited visibility of follows/followers
* Suitable for single board computers
2021-01-24 13:12:04 +00:00
* Progressive Web App interface. Doesn't need native apps on mobile
2021-01-24 13:11:37 +00:00
* Integration with RSS feeds, for reading news or blogs
* Moderation capabilities for posts, hashtags and blocks
2019-08-29 11:16:33 +00:00
2021-08-03 16:10:29 +00:00
## Non-goals
2019-08-29 11:16:33 +00:00
2021-03-16 21:52:03 +00:00
The following are considered anti-features of other social network systems, since they encourage dysfunctional social interactions.
2019-08-29 11:16:33 +00:00
2021-01-24 13:11:37 +00:00
* Features designed to scale to large numbers of accounts (say, more than 20 active users)
2019-08-29 11:16:33 +00:00
* Trending hashtags, or trending anything
* Ranking, rating or recommending mechanisms for posts or people (other than likes or repeats/boosts)
2021-08-03 16:10:29 +00:00
* Geo-location features, unless they're always opt-in
2019-08-29 11:16:33 +00:00
* Algorithmic timelines (i.e. non-chronological)
* Direct payment mechanisms, although integration with other services may be possible
* Any variety of blockchain
2021-08-03 16:17:03 +00:00
* Anything based upon "proof of stake". The "people who have more, get more" principle should be rejected.
2021-08-03 16:18:53 +00:00
* Like counts above some small maximum number. The aim is to avoid people getting addicted to making numbers go up, and especially to avoid the dark market in fake likes.
2019-08-29 11:16:33 +00:00
* Sponsored posts
2021-01-24 13:26:15 +00:00
* Enterprise features for use cases applicable only to businesses. Epicyon could be used in a small business, but it's not primarily designed for that
2021-03-16 21:52:03 +00:00
* Collaborative editing of posts, although you could do that outside of this system using Etherpad, or similar
2021-01-24 13:11:37 +00:00
* Anonymous posts from random internet users published under a single generic instance account
2021-08-03 16:10:29 +00:00
* Hierarchies of roles beyond ordinary moderation, such as X requires special agreement from Y before sending a post. Originally delegated roles were envisioned, but later abandoned due to the potential for creating elaborate hierarchies
2021-08-03 16:12:57 +00:00
* Federated blocklists. Initially this seems like a good idea, but the potential down sides outweigh the benefits. eg. Two allied instances share their global blocklist. Some time later one instance is transferred to an adversary, or gets hacked or sold. Adversary can now control your global blocklist and trash your instance very quickly that way.
* Federated moderation. Again, seems like it might be beneficial initially. Share the burden of moderation. But under realistic conditions people could be pressured or bribed into giving federated moderation access, and the consequences could be very bad. Individuals going on power trips, controlling multiple instances and heading back towards centralization. Avoid creating technical routes which easily lead to power consolidation and centralization.
