With the onset of Cancel Culture and the hyper-politicized society we now live in, online communities are struggling with finding homes where they are able to speak freely with worrying about censorship or banning. Organized and structured communities usually have some manner of gatekeeper requirements, and their own internal content moderation rules. So the rules imposed by the platforms end up doing more harm than good to such groups.
Wingate provides a social media platform for private networks, and to enable the formation of Virtual Social Netorks through Bi-Directional Federation. To make this work as a user expierence, it implements a core Post model which can be abstracted to mimic the best aspects of a variety of systems into one:
- The immediacy and broadness of Twitter
- The content creation magic of Slack
- The threading capabilities of a forum/BBS
- The content structuring of a CMS
- The media handling of a photo-sharing platform like Instagram
Wingate also provides the ability to form Virtual Social Networks by enabling Wingate-based communities to share Channels via bi-directional federation. Most current federated systems are essentially just “RSS On Steroids”. You can subscribe to a stream to read, but you cannot reply. With bi-drectional federation, shared channels allow full participation from members on every subscribed server. Community managers are thus able to expand the reach and visibility of their servers by subscribing and sharing with others. Of course, all of this is governed by the community standards of the people actually involved, as opposed to some faceless cabal in Silicon Valley.
This system is intended for either existing large communities which currently reside and/or interact on the large social media platforms, or for social media influencers who have large followings and wish to interact with their community in privacy.
While many systems are rushing to adopt Blockchain technology (and Wingate Development is exploring that as well), Wingate has adopted a strategy of a “Submerisble Platform”. The assumption is that any online system, even one run on Blockchain, can be de-platformed if someone really wants to. The idea behind a Subermisble Platform is that, much like a submarine, the server can be taken offline when it comes under threat, relocated to new hosting, and then re-surface several hours later without missing a beat. To accomplish this, the system is built using an industry-standard, easy to deply, and open-source technology stack - making it possible to deploy (or re-deploy) an instance easily on any Linux box with power and connectivity.
Wingate doesn’t intend to compete directly with the likes of Twitter, Facebook, or Slack. Rather, it intends to provide a private and self-regulated platform which incorporates the best of these other networks into a private-access platform. In other words, it’s an alternative to allow groups which may already be ‘private’ to have an instance that they have control over and do not need to worry about external policies interfering with their group.
The system is built around a central Post model which is flexible enough to be used in multiple ways. Posts are associated with Channels, which act mainly as a container stack for a group of related Posts. The Channel object is where the behavior is implemented. This allows discussions to move from one mode to another if it would be better suited there. For instance, a user may want to promote a very thoughtful forum post to be a blog post. The behaviors are as follows:
A Timeline Channel works like Twitter/Slack. Posts are displayed like a Tweet in chronological order. Only a short preview of the Post is shown within the timeline display, which can be expanded in a modal to show the complete post.
A Forum Channel behaves like a traditional forum. Posts are completely threaded and a new Post represents the start of a Forum topic. This will better accommodate longer-form Posts and discussions, or discussions which will persist over a long period of time (such as “announcements). In Forum mode, full Post bodies are displayed within the topic thread.
A Blog Channel is public facing. Any new Post in a Blog Channel is the Blog Post itself. Any reply to that original Post is treated as a “comment” in terms of how it is presented on-screen. Unlike traditional Blogs, though, comments are only available to community members. If the owner wants to incorporate an external commenting service, that capability will be available.
A News channel allows members to quickly post links to news stories. The system generates a preview block from the link and then provides a space for the community to discuss.
A Links channel is kind of like a News channel except the links are to non-news resources. Online communities tend to have lists of providers or products they like to use, or the members have businesses they’d like to list in a directory. A Links channel provides this mechanism, plus discussion capability.
A Gallery channel works much like a News channel, except that rather than highlighting a link to a news item, it has an uploaded image. These are presented in a grid format, and clicking on a grid tile opens up a page with a full view of the image plus the ability to comment and discuss. This can be used for everything from a photo-blog to sharing memes.
Systems like Twitter and Slack are great at managing large numbers of Posts, but they’re not great at structuring that content. The end result is very long streams of Posts and no way to really catch up on what’s important. Lists on Twitter help, but they’re limited. The following filtering and organizational features are supported:
- Posts can be tagged and filtered by keywords (hashtags) or users (mentions).
- Moderators can “pin” tags to a Channel so that they’re available on a menu for all members to quickly access. This provides a dynamic “folder” kind of metaphor.
- Users can “save” tags for quick-access from a menu. This allows members to collate Posts based on tags they’re interested in.
- Lists can be used to aggregate Posts based on including both tags and users. This is a departure from Twitter where only users can be included in a list.
- Users can save any user profile, post thread, or tag as a favorite on another quick-access menu. Favorites cross-cut Channels in that they are available across the system.
- Timeline Behavior Posts can be filtered by mentions, threads, Posts having links, Posts having media attachments, Posts having polls, and Posts having calendar events.
Posts can have a variety of additional content associated with them, much like posts on other social media platforms. The attachments can be any of the following:
- Uploaded images - a preview of the attached image is shown in the timeline.
- Embedded links - a preview of the first link encountered in a Post is shown in the timeline.
- Calendar events - an event can be added using Post shorthand as
/event Monthly Meeting, 2020/09/10, 10am. This will embed a downloadable
.icsfile which members can load into their calendars. When replying to a Post with an event, members will be able to confirm with shorthand such as:
- Polls - a poll can be added with Post shorthand as
/poll Should we go for drinks?, yes, no, maybewhere the first item in the list is the question, and the rest are the possible answers. A shorthand command will be available to close a poll as
/close. Votes can be registered with
- Each user has an automatically managed list of other users they have invited to the system. This makes it easier for users to interact and track people they have recruited to the community.
Unlike other system, Wingate will have a bi-directional Federation system. So subscribing instances not only can see the feed of content from another instance’s published channel, they can also post to it as if they were part of the publisher’s community. This will use a proprietary message bus system based on Redis.
Since there can be multiple subscribers to a published channel, this allows the creation of Virtual Social Networks between Wingate instances. Imagine a parent instance called “Home Plate”. It publishes a Timeline (“Twitter”) channel called “The Diamond”. There are three subscribing instances called “First Base”, “Second Base”, and “Third Base”. “Home Plate” owns the channel and decides whether or not to allow subscribers. But once the connection is made, each subscribing instance (“First Base”, etc.) sees new published posts on the message bus, pulls them off, and internalizes them. Subscribed posts are indexed as normal posts, but the content is stored also in Redis with an expiration timer. This way remote storage of content is ephemeral and less prone to attack.
When a subscriber wants to post into the channel it makes an API call to push a new item onto the publisher’s message bus. Redis 6 allows ACL, so it’s possible to give access to a limited set of keywords for the sake of running the bus. The publisher then pops the request off the bus and re-publishes it to all subscribers (and itself) as if it originated organically.
Namespaces will be represented as “@user!instance” or “channel!instance”. Tagging proceeds as normal on publisher and subscribers, and mentions are namespaced accordingly. The net result is a bi-directional bus which is highly fault tolerant due to the Redis LIST command - if a subscriber goes down, any bus requests it missed will still be waiting for it when it resumes operation (modulo how long it was down relative to expiration timers).
Wingate is now in pre-production. It has been running with a couple of smaller communities for around six months. The single-server implementation is almost feature complete, at which point attention will be turned towards building out the Bi-directional Federation code. This will run across a Message Bus built atop industry standard Redis in-memory storage. Provisions will also be added at this time to permit subscription information and user profile information/subscriptions to be persisted in Blockchain.