Relaxing treatment of non-notes by Mastodon
-
@erincandescent @darius if the actor represents me, then it is "my" inbox.
the correct solution imo is to spin up more bespoke actors. i'd really like to build upon the concept of "programmable actors", i.e., actors that are automated to act a certain way with activities they receive in their inbox. for example, a Relay could be defined as a programmable actor that Announces the object of any Create it receives, or Announces any activity it receives, or whatever. and it should be a JSON-LD type
-
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh @erincandescent @darius neat! The https://github.com/evanp/bots-rodeo/ platform is supposed to do just that.
-
-
-
Matthias Pfefferlereplied to infinite love ⴳ on last edited by
@trwnh @jenniferplusplus @erincandescent @julian @mike @hongminhee @thisismissem @michael @renchap
ActivityPubSubHubbub!
-
@erincandescent @darius I think I'll win the war because I have more actors on my side
-
@erincandescent @darius I will not stop until ActivityPub is a turing-complete computing platform
-
Darius Kazemireplied to infinite love ⴳ on last edited by
@trwnh @erincandescent turing completion considered harmful
-
@erincandescent @darius This! Let me create Collections that represent arbitrary subsets of my followers. Let me address them. Stupid sharedInbox makes this "inefficient", though.
-
infinite love ⴳreplied to Darius Kazemi on last edited by
@darius @erincandescent *me reading that activitypub uses actors and an actor model* ah so i can spin up an actor for every object in my object-oriented design program that runs on the ActivityPub Virtual Machine. i love being a computer scientist
-
@julian for all its discussions and arguments about issues with interop in activitypub, the upside is that this discussion is all happening on an actual-to-god forum, with everyone participation via their microblogging account.
browsing the thread from the nodebb interface is soo different than via your microblogging interface
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@darius @erincandescent actually isn't this more or less what spritely goblins is for
-
@[email protected] yes, there are pros and cons (but mostly pros!)
The one con is that microblogging tends to encourage a more bush-like tree, with many separate conversations that can trace their lineage back to a root node. A forum with a linear interface can and does struggle at times with that use-case.
The solution is, of course, to fork out a subset of the conversation into a new topic/context, but there is currently no
as:Fork
activity, and therefore no support *sheds tear* -
Darius Kazemireplied to infinite love ⴳ on last edited by
@trwnh @erincandescent dark magic that I leave to Christine
-
@thisismissem @trwnh @julian @pfefferle @manton @samsethi @renchap @andypiper Beware those stop gap solutions that become permanent instead of temporary in nature.
-
-
@julian I recently got interested in building topic-first discovery of content/conversations (Slack/Discord-like groupchat rather than "microblogging" which emphasizes recency and user identity). I ended up relying on Mastodon's hashtags (which users can already subscribe/follow), and elevating them in the user interface (a Slack-like sidebar which lists user's followed hashtags). But this bakes in certain expectations about topics/hashtags - how permanent and universal they are. Forking out a subset of the conversations into a new "topic" raises so many questions. "Topics" really is a big can of worms.
Another frustration I ran into with Zulip requiring a "topic" for every new thread was, how much user friction it introduces. Discord solved it by automatically inferring a topic or thread title whenever a thread is created. Would like to see more of this (more organized content, without burdening the user but still allowing them to re-organize).
-
@julian @thisismissem @hongminhee @pfefferle Our primary view for longform content (articles) is an inbox/reader list of posts - where it makes sense to show a preview (as inboxes and readers do) before opening. Preview requires an object, so as:Note felt like the most logical object to fit there. We're mainly using this for Ghost<>Ghost atm.
-
John O'Nolanreplied to John O'Nolan on last edited by
@julian @thisismissem @hongminhee @pfefferle Separately, Mastodon are doing great work and have a non-stop barrage of feature requests (often: demands) from all sides, and everyone is convinced theirs is the most critical (ofc).
We've chatted to them about long-form, and they're well aware
They don't need importance impressed upon them, but they certainly do need funding and PRs — so I think you're very much on the right track there!