I want an app for composing and posting long form text. Where I can choose where I want to post it, on a main feed or just into the feed for a group, and public-facing or just for the followers of that feed.
An app that can post to more than one fediverse account simultaneously (MissKey? Ghost? Lemmy? PieFed? All 4?), that would fit the bill.
But what if @Mastodon interpreted Followers-only as 'group(s)-only' when only groups @mentioned?
(1/?)
@evan
> we have a task for working on groups at the W3C. You should help!
Thanks for the invitation, I'd love to help. But I resolved a while back not to contribute to anything that requires me to login to GritHub. For reasons that SFC sum up nicely here;
... and from an individual developer's POV here;
https://lord.io/leaving-github/
If there's a mailing list or anything I can join without an account on a DataFarming platform, please let me know.
@Mastodon Is there a way for Mastodon to identify an Actor as belonging to a group rather than a personal account, while still keeping the @name@domain.foo format people are used to? Is there a standard by which forum-like fediverse apps like Lemmy and Discourse, and others that support groups like Friendica and PieFed distinguish between accounts Actors and group Actors?
If not, maybe that would make a good FEP?
(2/?)
@Mastodon While I'm on the topic of FEPs...
The ones that I've skimmed are long. Eg FEP-1b12: Group federation;
https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md
... covers a bunch of different aspects of making federated groups work. Could there be value in a more microformats-style approach?
https://microformats.org/wiki/about
So the smallest unit of FEP covers the smallest possible standard it makes sense to describe. But then there are standard ways of clustering them by usage. Thinking out loud here. Bear with me.
(3/?)
@Mastodon My goals here are 3-fold;
* Make each unit of FEP easier for newbies to understand and implement
* Make it easier to understand how FEPs combine to form the basis of different types of social platform (microposting, blogging, groups, media hosting etc), while others are added to support specific subtypes (private groups, public forums, podcasting, short video, etc)
* Make the AP/ AS specs easier to understand, by providing more context for what they enable in practice
(4/?)
@Mastodon I'm envisioning a system where the smallest unit of FEP uses the current naming scheme (a hexidemical hash of the human-readable name or somesuch). Then there is a parallel naming scheme that defines and numbers the social platform types and subtypes.
(5/?)
@Mastodon So if Alex decides to federate their music hosting platform, they can search through a fairly short index and find the 3.3 Music Hosting spec.
That spec start with a reference to the 3.0 Media Hosting spec, which lists all the AP sections and FEPs that MUST be supported to federate media hosting. Then briefly describes how they fit together. The 3.3 spec then does the same for any other FEPs specific to federating music hosts and not mentioned in 3.0, essential or optional.
(6/?)
@Mastodon Rather than expecting Alex to start by trying to read the ActivityPub spec - which is vague by design to make it general purpose - they could start with 2 fairly short spec that are specific to the problem they're trying to solve. Giving them a list of bite-sized FEPs to implement, and some context for what each one contributes to the whole.
Understanding FEPs will often require reading bits of AP, AS or AV. But by the time they do, they'll have some sense of what they're for.
(7/7)
