on adding monsterfork features

[aescling]

Plural Café uses a fork of glitch edition which includes several versions of monsterfork in separate branches; this may be worth looking at!

for an examples of the kinds of things monsterfork would do, it would

• enforce that no replies were allowed for posts content warned “:dont_at_me” and a couple variations thereof;
• support bangtags!---various commands processed server-side to do all sorts of cool and scary (in terms of implementation details) things.
  • this is one way we could implement pseuds i guess (#!i:am / #!we:are);
  • it also provided access to the glitch edition and mosterfork APIs to clients which only understand “base mastodon”, so to speak
  • bangtags ended up also being associated with adding various features like server-side drafts, and
  • status updating (including of metadata; it was even at one point possible to retroactively make private posts and DMs publicly visible by their URI---like i said, cool and scary things!);
• add lots of privacy-oriented changes to the way federation works (i never paid much attention to this, but there'a a lot going on here); and
• allow muting notifications for entire threads;
• extra content types for posts;

and so on, and so on...
(note that Plural Café has not merged most of monsterfork to main; but the admins clearly wanted to make sure monsterfork stuck around)

we’re posting this as an RFC because monsterfork was not necessarily implemented with clear design goals so the feature set ended up being arbitrary (but very very cool!!!), and, from what i saw from multiple_creature’s posts, even more difficult to maintain than mastodon already is. so i feel like adding features is a potential minefield. also this would probably distract from KIBI’s extremely good and reasonable goals; maybe this would be best considered later when we've solved other things?

imporantly, if to state the obvious: as this is community software, we should note this would only really be worth doing if our users needed (or really wanted) monsterfork features. so much of this RFC should be about discussing if there are things in monsterfork we would actually even want!! lol. not to mention, where in the commit history those features even are (again, lol)

thoughts?

[marrus-sh]

My thoughts:

• I’d like noreply stuff to be federated, so this will need to be hashed out architecturally before we implement it. It’s probably a big conversation regarding a lot of pros and cons and questions about lack of support elsewhere. But I’m definitely not opposed to the idea conceptually.

• I would rather formalize and extend post sigils (the local‐only eye being the one we currently support) than add a bangtag syntax; it clearly and unambiguously limits them to only appearing at the end of the post (rather than intermixed with content), which i think is a good thing. If sigils alone aren’t enough, we should combine them with a more sophisticated technology, like YAML frontmatter. (I’d like to improve display of sigils in the default Mastodon frontend so they are more clearly distinct from content.)

• Pseuds, if we implement them, I want to be semantic and federated (ideally, mentionable with Webfinger lookup). I have thoughts regarding this but there are a lot of pieces to put into place and it should probably be its own thread if you want to talk about it now.

• Most of the privacy‐oriented changes in how federation works are achieved by AUTHORIZED_FETCH mode; I’m not sure there’s actually much, if anything, for us to do there. (I believe monsterfork predates AUTHORIZED_FETCH.)

• I believe you already can mute notifications for threads? What you can’t do (I don’t believe) is mute them from your timeline.

• Before we go adding extra content types for posts, I’d like to make sure the content types we have work well, and also work on formalizing our post representation into something which doesn’t rely on things like <span class="invisible">.

[aescling]

what do you mean about post sigils, exactly? do you mean something like having a tag at the end that is effectively metadata about the post? (so a pseud or signature, local only post, etc?)

[marrus-sh]

The way local‐only toots work (well it’s a little more complicated than this but essentially) is, when a thing hits the API to create a new post, it scans the end of the post for an eye. If there is an eye, it sets the local‐only flag.

By “sigils”, I mean “things at the end of the post that it scans for [like an eye], which result in certain transformations [like setting the local‐only flag]”. I’m specifically imagining these as constant values (no arguments), and probably ideally shortcodes (like, hypothetically, :local_only:), with the caveat that undefined shortcodes are rendered as a Unicode emoji (like 👁).

(But the specifics of this are of course open to discussion.)

[marrus-sh]

I feel like I should add that while I think we should prioritize GlitchCat features, we shouldn't reject features simply because nobody on GlitchCat has a strong opinion on them. We are currently the only people equipped to run a proper (significant) fork of Mastodon (believe it or not), so if we can easily meet a broader fediverse need, it might be worth making the attempt.

This is irrelevant for the rest of 2021 because we’ll have our hands full with the stuff already on the table for at least that long. Unless we get outside help, in which case, anything’s possible.

[marrus-sh]

@single-right-quote Do you know if there is a listing of bangtags anywhere? It’d be good to have as a reference.

[aescling]

oh! i just remembered a monsterfork feature that i particularly remember being very good and would like to see; i forget if this was an option or just what the front end did, but it would display the full image description below the media it described. i particularly miss that

if we implement i think it should be both optional and collapsible

another interesting way we could do it, which monsterfork did not do but i would have liked, is to collapse media behind its description. there was a time before monsterfork properly hid descriptions behind content warnings when i would use the image description to decide whether i was even interested in opening a post to see the image

[marrus-sh]

I’d probably just implement this as

<figure>
  <img /> <!-- possibly hidden -->
  <figcaption></figcaption>
</figure>

which is fine and good.