The WL Frontend - Featureset Discussion

No Numbers.

This is, like Cohost, intended to keep parasocial and compulsive tendencies about social interactions to a minimum.

• On user pages: No count of posts made

• On user pages: No count of followers, or following

• On posts: No count of likes/favorites/upvotes/downvotes

• On posts: No count of reblogs/reposts

• On the user's frontend: Potentially allow counts of notifications total, for a user's own notifications

• On the user's frontend: Potentially allow one notification per interaction, modeled after Cohost's

  • Do permit users to disable notifications for any interaction type.

• On instances: No counts of total users, except visible to node staff

• On instances: No counts of total posts, except visible to node staff

• Permit exceptions to the above as needed for moderation or operational duties.

Am I missing anything?

Worth noting that pillbug by viv is already a pretty good starting point https://github.com/vivlim/pillbug

my announcement post for pillbug defines the approach i'm taking to achieve cohost-like structure.

this is the heart of how i plan to achieve a cohost-like structural abstraction over top of activitypub statuses:

the core idea is to contextually re-interpret "statuses", which are the tweet-like objects that mastodon-compatible servers exchange, as cohost-like analogues in an attempt to approximate the feel of using something less like micro-blogging and more like cohost.

my current thinking on how to approach this:

• a status which is not a reply to another status, is a post

• a status which is replying to another status is a comment. it will not be shown in the home feed (maybe this will be toggleable, but for now they're just skipped over)

• a boosted status is a share without any addition.

• if a root status A contains a link to another status B, A is interpreted as a share of B; B is fetched and glued to the top of A. If B contains another link this happens again.

here's a loose braindump of design goals and thoughts i have in mind. a lot of this will need to be prioritized, i focused on getting the ideas out of my head and written down.

• structural abstraction: it's not twitter-shaped, it's cohost-shaped.

• not a 1:1 copy: i'm not building an exact replica of cohost on top of activitypub. i'm building an experience that is shaped like cohost. it's not going to be exactly the same.

  • but it is going to show few-to-no numbers and the feed is paginated.

  • doesn't interrupt you to say new posts happened while you're going through pages of the feed. realtime notification is used thoughtfully and may be turned off.

• customizable: i don't envision pillbug as an opinionated one-size-fits-all experience. "cohost-like" sets the stage and shape but you should be able to change what it looks like. ideally your instance could configure parts of the look too. initially just colors but having totally wild themes be possible would be neat. i'd like users to be able to shove css (and maybe scripts?!) into it without needing additional plugins!

• single-page application: like phanpy and *phore, you can log into it regardless of whether your instance deployed it. however, it could optionally try to read a `pillbug.json` config file from the instance's domain, giving instances an opportunity to inject their own configuration without having to build it themselves.

• gotosocial support and features prioritized: ideally, the entire gts /settings panel would be reimplemented within pillbug so there's no need to leave it to change your profile or do admin tasks.

  • it should try to be compatible with other servers (especially ones used in the league, like akkoma)

• 'preview' posts that are in progress: this is a necessity for longer content.

• drafts: implemented using local browser storage and/or self-DMs. it'd be good to be able to pick up a partially written post later on the same computer. it'd be better to be able to pick it up from your phone (or vice versa)

• responsive ui: is comfortable to use on a desktop and phone

• not bewildering to less technical users: it should not feel obtuse or overwhelming. however the goal is not a streamlined simplicity at the cost of power user features. it should feel like a posting website that has some extra stuff going on under the hood if you care to take a peek.

  • example: currently you can right click the part of a post where it says '0 comments' and toggle being able to see the raw post json. i would not take that away, i think being able to see what's going on under the hood is valuable. but since it's hidden in a context menu, it's not overwhelming.

• explains key concepts: doesn't assume you know things like what the different post visibility levels mean. help text and links are unobtrusively available

• takes care to not reduce browser functionality: the only concrete example i have off the top of my head is the right click menu.

  • only hijack right click when it does extra stuff, otherwise lets the browser handle it normally

  • strives to not take away browser functionality, only augment. so if you right clicked a hyperlink in a post, you should still be able to copy that link, but also be able to view it on the original instance in a new tab, or in pillbug in a new tab.

• pattern-based muting and muffling of content by tags, content, maybe even user profile text

• error reporting: shown errors are as actionable as possible to help users and node admins figure out why problems are happening. doesn't obscure issues

• telemetry: never automatic metrics that users must opt out of. consent is mandatory. opt-in client-side error reporting for league nodes could be really useful for understanding issues though. i mostly care about being able to identify and fix problems that are happening in the client without someone needing to go through the trouble of writing an error report.

• works outside the league: you should be able to use pillbug on non-league nodes and it'll still work

• multi-account: lets you log into multiple accounts and swap between them with the ease that cohost had

• stretch goals/future

  • embedded content, like hotlinked images: allow this but interactively request user consent that covers all the scenarios of:

    • informing which domains will be contacted to fetch the media

    • allowing all media in the post

    • allowing all media from specific trusted domains

    • allowing all embedded media in all posts, and don't ask again (with appropriate information presented to the user)

    • deny media in a certain post

    • deny media from a certain domain

    • deny all embedded media, period, and don't ask again

  • css crimes. this category is loosely defined at the moment but... support for viewing, previewing, and authoring these

One thing I think would be neat is a way to prevent the long "liveblog thread" problem you see on tumblr an its likes. When a user keeps updating a thread, it is not only pushed to the top of your timeline, all its previous versions also exist in your timeline.

A solution could be thus:

• A is an original post.

• B is a rebug with a comment to a

• C is a rb comment to B

• D is another rb comment to B

On the timline, these display as follows: When A is posted, you see thread A. When B is posted, you see thread AB, but not A. When C is posted, you see thread ABC. when D is posted, you see thread ABD first, then ABC later on in the timeline.

Oh: basic accessibility features, screenreader compatibility, alt-text, customizeable fonts & colors. It'd also be nice for it to warn you if you're posting an image that doesnt have a description.

Font size. Ya can't change font size in the akkoma frontend. That's real bad

@vis (couldn't find the facepalm emoji so see-no-evil monkey it is)