ERROR 301 (@realcaseyrollins@pleasehug.me) @realcaseyrollins@gameliberty.club

america wasn't a bad idea.

Gotta be in the #Fediverse works.

@wowaname @mewmew @r000t

I'm helping @alex with trying to define optimized front end specs. I would like to make a list of use cases, then look at best practices and define an overall spec, bounced against what is available in current and anticipated back end systems. I'm seeing some good ideas in this thread.

I am more of a strategist/architect/user than a developer, so I'm currently using Google Doc for collaboration efforts, but can adapt as necessary. It seems like there is a need all around for defining a next gen front end UX.

Ease of use, small learning curve, user configurability, system responsiveness, and productive social interactions would be some of the goals bounced against a UX use case discussion.

I have started creating a Google Doc to analyze UX elements, how they are currently applied and how they could be applied in an optimum federated social media UX. Here is a comment link. I have just begun the process.

https://docs.google.com/spreadsheets/d/1ClwvYS8ZIkzSUBrnIg53Spia-UuUvFHWTZVeVhv0De8/edit?usp=sharing

I have also created a Federated Social Media UX Use Cases Analysis spreadsheet, which will be addressed after the UX elements sheet is filled out. Here is a comment link to that spreadsheet. I can add editors if the effort takes off.

https://docs.google.com/spreadsheets/d/1oBtsfipsQsGG-LPEDx5PshJU4oIzR8naGog3Ukh9y30/edit?usp=sharing

question: who here is interested in an activitypub implementation that:

- has just an api, no default frontend, but can work with existing frontends and clients
- is developed with unix philosophy in mind, with interworking utilities controlling various aspects of the backend (one for static site/thread generation, one for the server api, one for client api, and then separate filtering utilities like postfix milter). this also means i want to "keep it simple and stupid" and not focus on dumb features only a few people want, but also have it be flexible enough that people can hack on it how they please
- is focused on moderation features (both instance-wide and self-moderation) including giving individual users the ability to filter ("MRF") as well as mute/block users and instances, all server-side, in a way that *makes sense*
- has *no* notion of public/federated timeline, but makes up for it with lists, thread following, hashtag following, "stalking" users or instances (seeing only their public posts and not actually following them)
- has scopes that make sense and likely dont map 1:1 to mastodon's shitty scope system – mainly, because there's no public timeline everything would be "unlisted" by default, but these posts should still be searchable by hashtag or context searching; additionally the "follower-only" scope should actually focus on not breaking threads (which should be fairly easy unless im missing an important detail... if it isn't easy then i'm willing to ax support for follower-only in its entirety, it isnt that important)
- uses authenticated fetch from the beginning – i dont really care about the politics behind ocap; it's perfectly clear that the current AP model is confusing to everyone, doesn't meet "principle of least surprise", and isnt suitable for a real social network. gnusocial was treated more like a *public forum* and not a social network, and it's only the gnusocial fanboys who impose their ideas onto AP. they ignore the "freedom of association", some people are more private/reserved than others and want to be able to control both how they present themselves to the network, as well as what they see on their home timeline. from what i understand, ocap will *not* prevent people from making their posts public, it shouldnt prevent being able to search for phrases or hashtags or users, it's simply a way to solidify the existing policies that are present in AP
- has plans for federated quotes and groups. some AP implementations already have both, it's just down to standardising how stuff interacts between implementations, and that means talking to other implementors

i know this is all ambitious (especially the later stuff which makes protocol assumptions) but imo its only worth it to do it right, or not to do it at all

i think some of these goals coincide with what @r000t is doing with his client, so i'd appreciate input especially from him

i need an incentive to do this. while ive wanted to work on this for a while, its yet another project i'd be starting work on when i havent finished a lot of other stuff. so i want to be able to commit to it and get something out of it

"The foot feels the ground."