All the basic functionality is in place, such as making posts, scopes including direct messages, blocking and filtering, content warnings and moderator functions. It's implemented in a manner similar to an email MTA with posts being stored as files in directories rather than within a database.
Why yet another ActivityPub server?
There are many ActivityPub servers out there but there are currently really only two which are suitable for general social networking rather than particular niches: Mastodon and Pleroma. Other systems like Friendica may federate with ActivityPub instances, but internally use their own protocol [correction - it does natively support ActivityPub among other protocols]. Most of the server code on Github or Gitlab is either very early stage development or abandonware, and it's expected that abandonments happened because the developers soon realized that it was a more involved task than the few available tutorials imply. Bigger than a weekend hackfest. Mastodon is ok but not well suited for running on low power hardware such as ARM boards. Pleroma is more suitable for self-hosting, but its limitations were becoming increasingly obvious when confronted with more serious levels of adversarial activity.
Also there were questions of depth versus breadth. Traditional social networking was about casual gossip and posting news links, but perhaps they could also be organizing tools to build communities with more depth and resilience to them. Beyond the state and the corporation, better ways to organize are needed if existing institutional intransigence is to be treated as damage and routed around.
Some extra features have been implemented which go beyond the current ActivityPub spec. Shares is a system for exchange of physical items, similar to freecycle or bartering. The idea is one of local non-monetary exchange and the development of pooled resources between trusted mutuals.
Skills allow you to publicly indicate what skills you have. Combined with a search function this perhaps makes it a little easier to search around within a trusted group for people to form a team with the needed combination of skills. People can of course indicate skills which they don't possess, but the ordinary mediations of a social network (blocking, filtering, peer pressure, etc) should make it feasible to remove dishonest actors.
As the internet and social networking mature it has become apparent that the threat to good order is not anonymity or even pseudonymity but unmoderated spaces. Rather than enabling maximal freedom as intuition might suggest, unmoderated spaces instead create a pressure cooker of maximal tyranny in which bad actors can carry out a reign of terror. Neither corporations like Facebook nor government regulations can create healthy communities merely by decree. People have to learn to govern themselves within the online space.
Epicyon includes moderation functions whereby the admin can assign other people to act as moderators enforcing the terms of service, which can be customized as needed. Members can also report suspicious posts to the moderators.
Emoji are of course implemented using the OpenMoji icons. It's also easy to add new emoji to the list. Unlike some other social network interfaces there is also the ability to search for particular emoji rather than trawling through a gigantic list.
Currently attachments can only be images. There isn't yet support for video or audio, though that may come in later versions.
The Mastodon API is also not implemented and this means that you can't currently use Epicyon with Android apps such as Tusky. This also might be added in a later version.
The familiar timelines (local, federated, etc) which originated from StatusNet also aren't implemented. ActivityPub only defines inbox and outbox, just like email, and that model has been stuck to. This may be easier to understand for people new to the fediverse, since most people already have a mental model for the way that email works.
There is currently no push mechanism between the server and a web browser. Instead it performs a primitive meta refresh every few minutes. This is obviously not ideal for mobile, and may be improved upon in future.