from julian@community.nodebb.org to swicg-threadiverse-wg@community.nodebb.org on 16 Sep 2024 15:52
https://community.nodebb.org/post/101006
re: better handling of non-notes by Mastodon
Toward the end of a day 2 FediForum session, @pfefferle@mastodon.social, @manton@manton.org, and I sidetracked a bit and discussed once again the tendency for implementors to shift away from more suitable ActivityStreams Activities to as:Note.
Specifically, it was the demo/session by @samsethi@podcastindex.social re: TrueFans. Instead of federating out an as:Listen, they send as:Note, and it's a fairly safe bet that this is because the content cannot be richly represented in Mastodon. The same story played out with Mattias and the WordPress plugin, and myself with NodeBB.
Secondly, back in March/April and again in May, @renchap@oisaur.com mentioned that resolving this was of some interest to the Mastodon team:
We will work on improving the display of non-Note content in the next Mastodon version
To be clear, getting Mastodon to suitably process as:Article/as:Listen/as:Offer or any number of other activities is not what the ForumWG wants to accomplish. It's not up to Mastodon to adapt to the variety of content on the fediverse, but rather that its fallback handling needs to improve just enough so that its baseline rendering is acceptable to more implementors and their users.
As concise and actionable as I can make it:
- Mastodon allows a subset of HTML for
as:Note. This subset is good enough, butcontentin non-notes has all html stripped. Keep consistency here and allow the same subset of HTML. - Non-note
contentis truncated. This is no longer necessary due to the addition of the expand button. The wonderful thing is this standardization of behaviour actually simplifies Mastodon code. - Instead of appending the object URL to the status content, promote the "Open Original Page" button out of the overflow menu. It's more than okay to defer to the original site vis-a-vis presentation and allow the user a smooth exit if desired (
target="_top"would be okay too if you're worried!)
That's it.
You could even skip the third point, but even with 1 and 2 achieved this would sufficiently raise the baseline behaviour just enough that I would immediately update NodeBB to send as:Article for new topics, and I am certain @pfefferle@mastodon.social would adjust his defaults as well.
Lastly, @renchap@oisaur.com, I'm sure I can speak for everyone at FediForum when I say that it was wonderful to see representatives from Mastodon (that of course includes @andypiper@macaw.social as well) in attendance. It means a lot to me personally that you were there, and sends a signal that Mastodon continues to desire broader inter-compatibility.
#activitypub #activitystreams #fediforum #mastodon #swicg-threadiverse-wg
threaded - newest
@julian @pfefferle @manton @samsethi @renchap @andypiper
You know that post that uses nodeinfo to customise the received notes by software?
Yeah, we need that but for federation.
@thisismissem @julian @pfefferle @manton @samsethi @renchap @andypiper I don't think "capability negotiation by nodeinfo software version" is a good idea or at all desirable.
@trwnh @julian @pfefferle @manton @samsethi @renchap @andypiper
It's a stop gap solution until we have something better.
@thisismissem @trwnh @julian @pfefferle @manton @samsethi @renchap @andypiper Beware those stop gap solutions that become permanent instead of temporary in nature.
@renchap@oisaur.com it's an oft-repeated refrain that the Mastodon team has a lot of their plate. With bug fixes, existing feature pipeline, and now your funded work with fediscovery, issues important to other implementors might fall by the wayside or seem less important.
The easiest thing for us to do is to impress upon you and your colleagues the importance of this for the wider fediverse. You have @pfefferle@mastodon.social from WordPress, @mike@flipboard.social from FlipBoard, and @michael@newsmast.social from NewsMast, and likely others who would be on board (@hongminhee@fosstodon.org with Fedify/Ghost?) with switching away from
as:Note(I can't speak for them, but probably?)The second easiest thing here would be to have a developer make a PR against the Mastodon repo. I'd love to also make this happen (funding and such permitting).
@julian We are doing our best to improve our implementation where we can, but it often requires a lot more work than what it initially seems. PRs are very welcome, but should probably be preceded by reaching out to us and seeing if we agree with the proposed implementation, and if it covers everything that it needs to
@pfefferle @mike @michael @hongminhee
@julian Ghost already represents posts as `as:Article` objects. Interestingly, they put `as:Note` into the `as:preview` property of `as:Article` objects, which I don't think Mastodon utilizes.
https://github.com/TryGhost/ActivityPub/blob/46ef68e2c79ec9e8e3fb8d9e5ebbd0729c6bae72/src/handlers.ts#L58-L70
@renchap @pfefferle @mike @michael
@hongminhee @julian @renchap @pfefferle @mike @michael
That's an interesting idea using as:preview to carry an as:Note representation of the activity, abd would probably be pretty easy to integrate, I think?
@thisismissem @hongminhee @julian @renchap @mike @michael but isn't this a hack we only might have to add because of the summary/content-warning thingy?
@thisismissem@hachyderm.io @hongminhee@fosstodon.org Yeah that's something I haven't seen before. Would love to get @johnonolan@mastodon.xyz's take on it.
Blog software has the concept of "excerpts", which I think fits well with that idea.
@pfefferle@mastodon.social is right though... this is likely only because an excerpt can't be sent in via
summary, otherwise it gets treated like a CW.@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.
@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!
@johnonolan @julian @thisismissem @hongminhee @pfefferle except the maintainers have made it clear they do not want PRs unless you get pre-approval from them for your implementation plan or whatever.
@lkanies @johnonolan @julian @hongminhee @pfefferle for big stuff, yeah, talk to the maintainers before implementing — that is consistent for any open source project.
@thisismissem @lkanies @julian @hongminhee @pfefferle yup, 100% — You can't just walk into someone's house and start re-arranging the furniture and expect them to be pleased.
Always good to start with bugfixes & smaller things to learn the codebase, and for maintainers to get to know+trust you.
Once you've showed that you're going to stick around, you generally get more freedom and approval to take on larger things.
Source: Years of contributing to WordPress, long before Ghost :)
@johnonolan @lkanies @julian @hongminhee @pfefferle I can also attest that that's the case with Mastodon — I did a heap of small contributions before being able to drive bigger changes.
@thisismissem @johnonolan @julian @hongminhee @pfefferle that’s good to hear. Because… that’s not the way I see them talk about it. Literally every time someone talks about doing a PR, there’s a request for consultation beforehand. I’ve never seen that in any other community.
(It’s true that my OSS contributions were mostly quite a while ago. And a lot of them were to the project I started, which I absolutely did not run that way.)
@lkanies @johnonolan @julian @hongminhee @pfefferle
tbh, no open source maintainer likes suddenly receiving a sizable pull request out of the blue, it tends to be disruptive or require additional time input to review/correct/review, hence nudging folks towards discussing with the team first.
@thisismissem @johnonolan @julian @hongminhee @pfefferle totally. These just don’t feel like nudges.
And sometimes, those big pull requests are the only way someone can work. It doesn’t mean the maintainers owe the author anything. But there are a *lot* of people whose first step cannot be “have sizable organization and permission meeting with stranger”.
All of my major pre-puppet contributions started with experimenting with code.
@lkanies @johnonolan @julian @hongminhee @pfefferle In the past when the project has closed sizable pull requests, people have gotten pissed, so... yeah :/
@johnonolan @thisismissem @julian @hongminhee @pfefferle it’s only rearranging the furniture if they accept the PR, as you know.
OSS is supposed to be about permissionless innovation, so it’s weird to have to get permission first.
@lkanies@hachyderm.io well, if we're going to beat this analogy to death, then it's more like you're free to copy my house and everything in it, and re-arrange it (now your furniture) as you see fit.
I'd prefer if you didn't re-arrange my furniture though.
@julian I agree, you have beaten that analogy to death :)
You are welcome to do whatever the hell you want with code I post for free on the internet. And I am welcome to ignore all of that work, or not.
Nothing you do to my code intrinsically affects anything in my life.
@lkanies @thisismissem @julian @hongminhee @pfefferle it is permissionless innovation: In your own fork.
A pull request is a proposal to make changes upstream, if you want to do that then there’s nothing permissionless about it and never has been :)
Modern OSS maintainers are remarkably polite about it, too! Have a read through Linus Torvalds old mailing lists if you want to see how OSS really started. Big contrast
@johnonolan @thisismissem @julian @hongminhee @pfefferle thankfully Linus has never been a reasonable standard for how to treat other people, not now, and not then.
And there is a huge difference between “we will not merge your code without talking about it first” and “if you write code without talking to us, we will not merge it”. I hope you can see that.
@lkanies @thisismissem @julian @hongminhee @pfefferle and I think this reasoning has been explained to you in some detail by several people. Hopefully you can see that :)
@johnonolan @thisismissem @julian @hongminhee @pfefferle definitely a situation where neither of us is convincing the other 🤷♂️. But I’m just some guy with opinions on the internet (and experience in other OSS projects). My opinions deserve no weight here, so I will slink away
@julian @thisismissem @hongminhee @johnonolan but that's no longer completely true. You can send a `summary` if `as:sensitive` is false :)
only if `as:sensitive` is set to true, the `summary` will be used as content warning.
@pfefferle @julian @hongminhee @johnonolan
And if as:sensitive isn't set..?
@thisismissem @julian @hongminhee @johnonolan then Mastodon uses the `summary` as summary.
@pfefferle @julian @hongminhee @johnonolan
Hmm.. I wonder what @samsethi was hitting into the other day then? He said something about summary marking posts as sensitive incorrectly
@thisismissem @pfefferle @julian @hongminhee @johnonolan @samsethi did this change in a recent Mastodon version? Have client apps caught up with it?
@KevinMarks @thisismissem @julian @hongminhee @johnonolan @samsethi that is a good point! Maybe it is a client app thingy!
@thisismissem @pfefferle @julian @hongminhee @johnonolan We wanted to originally publish the activity out of Truefans using the Summary verb but it marked everything as sensitive. After some digging and help from the AP community it was a known bug so we switched to using Notes. We also tried the Listen verb but that didn't work in Mastodon or clones so we abandoned that idea. TreuFans will now build our own full AP client and support the verbs and display them correctly in our app.
@samsethi@podcastindex.social open to supporting
as:Listenif you publish it. Can you send me a sample activity, and what you expect? Embedded audio player, etc?@julian thanks, Yes an embed player so users can hear a clip in situ. I am not sure we want users to hear the full podcast episode in the AP client.
@samsethi @julian this seems like a weird expectation to me. As:Listen is an activity. It's a thing that the (sending) actor did, or is doing. It would make sense to put an audio clip in an audio object, but not directly in a listen activity.
Anyway, since I'm not building a podcast app, I would be inclined to interpret a listen activity as a kind of presence update. Like an AIM away message. If you want something like a share or recommendation, I would expect that to be an announce activity
@jenniferplusplus@hachyderm.io @samsethi@podcastindex.social yeah,
as:Listen(object)or some such.I'd have to refactor a bit since my code pretty much expects either Announce or Create, but it's for the better anyway.
@jenniferplusplus @samsethi @julian Pleroma uses
Listenactivities to display "currently listening" status: https://docs-develop.pleroma.social/backend/development/API/pleroma_api/#get-apiv1pleromaaccountsidscrobblesI think this activity can also be used for counting podcast listeners.
@silverpill@mitra.social Very cool, thank you!
Hopefully @samsethi@podcastindex.social will reconsider and perhaps federate out
as:Listenin addition <img alt="🙂" src="https://community.nodebb.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f642.png?v=cvahml4jj12">@julian @silverpill we will we have two more changes ot make to our AP client tomorrow. We just enabled any AP user/client to follow any podcast and get their new episode, play, comment etc actvitiy. But next week we will publish with the listen verb for clips and see what happens ... thank you
@pfefferle @hongminhee @julian @renchap @mike @michael
To a degree, but for activities like Travel, Listen, Visit, etc, I think representing those to something resembling a Note will always be difficult, hence having an as:Note preview of the activity does make sense to me
@thisismissem @pfefferle @hongminhee @julian @renchap @mike @michael hot take, but mastodon should be able to convert *anything* into a status "simply" by taking name/summary/content if present. https://www.w3.org/TR/activitystreams-core/#h-text-representations
@trwnh @thisismissem @pfefferle @hongminhee @julian @renchap @mike @michael but one thing I'd note: I think objects should always degrade gracefully into something note like, but that's not the case for activities
Imagine I used a federated last.fm like application. If Mastodon converted as:Listen to a note, my followers would probably get pissed off about the "Now listening to: X" statuses every 2 minutes
@trwnh @hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem back in pump.io these things were relegated to your "minor feed". Absent an equivalent, I think implementations *should* suppress them. If your use case isn't amenable to this behaviour, you should probably consider if an activity is appropriate for it
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
a combination of `streams` and followable Collection-actors is how i’d approach this. we don’t need to be stuck in a paradigm of sticking every activity into one outbox, nor should every activity always be sent out to all followers.
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
i think this is on the user/client to not publish/deliver every single scrobble to all followers. mastodon should still be able to render arbitrary activities if there is a text repr of them.
@trwnh @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap I think publishing every scrobble to my followers is how I expect federated last.fm to work. It's on recipients to hide these things
@trwnh @hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem I think the activity Vs object distinction is very important because it models a semantic thing that by default objects are important but most activities are not
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
i don’t find this to be the case. in this case the “post” is not the Audio object, it’s that you Listened to it. it’s actually far more common for the activity to be more important than the object.
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
this is like saying “i’m going to email every scrobble to my entire contact address-book and it’s their job to filter out such emails”
@trwnh @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap we don't really have a way of knowing what activities our followers are interested. In fact in the general case that's impossible; if I started using a music suggestion system based upon my friends listening habits today, I'd like to be able to use their historic listening data that they have been broadcasting to seed it.
Alternatively, consider that I decide to make my listening history public and it hits a relay. My as:Listen activities are going to absolutely carpet bomb the federated timeline.
Aside from the Annointed Two (Create, Announce) we really need to treat most activities as ephemeral and largely unimportant
@trwnh @hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem the idea that every activity should turn into an entry in my home feed is utterly ludicrous. Imagine if this applied to Like or EmojiReact
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
Why shouldn’t it? This is an app/impl decision. I could add name/summary/content to a Like. You can ignore those fields and “downgrade” it to being “just” a like, or you could render it in its entirety as a post (which is likely my intention in adding content in the first place!)
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
This is why we need to allow people to specifically follow certain Collections which are exposed as streams. It’s also why we need to allow people to send activities to arbitrary audiences which might not include all followers.
If a relay is set up for the purpose of aggregating Listen activities and you follow it, that’s on you. You asked for it.
Create is the exception, not the rule
@trwnh @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap You're right that create is the exception: it's just one of two activities that you actually want to directly see in a microblogging context
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
Ironically in a micro/blogging context, the Create is mostly not interesting, it’s just a wrapper for the inner object which is the real “post”. Although, this doesn’t have to be the case — the Create might have metadata of its own that is interesting. Or you might want to preserve the Create for the consistency guarantee that everything is a stream of specifically Activities.
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
In any case I’m arguing that the criteria for “post” or “status” in something like Mastodon ought to be “does it have content?” If it doesn’t, then there’s nothing to really convert into a status, unless you get clever about interpreting the Activity type and generating a status from the statement “<actor> <type> <object>” or “<actor> <type> <object.type>”
@trwnh @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap therein lies the point - activities mostly *aren't* interesting. Create and Announce are interesting not in and of themselves but because of what they carry.
Things just work much better in many ways if activities can be thought of as largely ephemeral.
If the podcast listen is important enough that it's worthwhile keeping around in my feed - say, it has commentary or something like that - then perhaps it's better framed as commentary, not as a pure listen
@trwnh @hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem I think our fundamental disagreement here is that I think activities shouldn't have content; it really opens many cans of worms
AS1 had a much more robust activity/object distinction and TBH I'm still kinda upset at how much AS2 muddled every type of object together into sludge
@hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem @trwnh if you treat activities as first class objects indeed of second class, it really opens up various cans of worms. What does it mean to like a like? Can you reply to an EmojiReact? Can you Like a Listen?
The end result of dividing things might be some semantic overlap between "small" Activities and "large" Objects, but that's probably not the worst possible argument
I do think there's an argument for a world with an activity-object merge but it's probably the world in which the Create activity never existed
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
You can do all of those things and they mean whatever the negotiated meaning is between the human author and the human audience.
From an AP machine view, Liking a Like just means that your Like SHOULD be added into the `likes` collection of that Like. From a human view, it simply means “I like that you liked this.”
@trwnh @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap and I agree, but I think this approach if actually implemented really combinatorially explodes the protocol. An implication of this direction of thought is that your like has a likes collection, and that likes collection has it's own likes collection, ad infinitum.
You really can express absolutely everything in ActivityPub/AS2 and it's it's biggest flaw IMO. The combinatorial explosion really paralyses implementers
@trwnh @hongminhee @julian @michael @mike @pfefferle @renchap @thisismissem if we got to do a clean slate do over, I'd commit to either full unification or separation of objects and activities, and also the "implicit collections" would not be reified as Objects (ideally we'd get structural addressing too: you'd be able to explicitly refer to a users followers - for example - without having to know the URL of the collection)
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @trwnh @michael @renchap
In that clean slate scenario, i would want to explore moving the information carried by activities into headers.
@jenniferplusplus @erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
We should go back to WebSub… and we should also go back to calling it PubSubHubbub :D
@trwnh @jenniferplusplus @erincandescent @julian @mike @hongminhee @thisismissem @michael @renchap
ActivityPubSubHubbub!
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
This is why it should be simplified to “just render the content/summary/name” for blogging-oriented apps. The combinatorial explosion is a consequence of hyperlinks. You can’t do away with it. Side effects should be progressive enhancements.
As a publisher, what you CAN do is decide not to put a `likes` collection on everything. This means that the Like of a Like has no side effects.
@erincandescent that’s probably it. I think whatever “can of worms” that contentful Activity objects bring to the table is just normal everyday expressivity. Why force yourself to publish exclusively a Create Note or even a Create Article when you can be more semantic and publish something more accurate to what you really did? Why treat the myriad Activity types any differently? If it were just about objects, we might as well generate feeds of exclusively objects and skip the Create entirely.
@trwnh I love how as we hash this out it turns out the two of us are in violent agreement and we're just disagreeing on the way to proceed from what exists
@erincandescent haha, I don’t think it’s violent! nor do I think it’s completely agreement, either — we probably still disagree about the fundamental nature of an Activity, for example.
To summarize, how I think we should proceed is that we should implement more generic support for text reprs of arbitrary objects, including arbitrary activities. My happy default is that any object with content is a “post”, and beyond that, you MAY choose to support contentless Activity types with side effects.
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @michael @renchap
This just feels like the justification for shoving everything into the Create-Note-shaped hole.
I think that any object, Activity or not, can be considered a “post” if it has content. Sure, there are additional semantics, which you can ignore if you’re Mastodon. You’re also free to add explicit support for certain contentless activities, such as contentless Like or contentless Announce
@trwnh @erincandescent fwiw I'm 100% on board for following Collections exposed as streams. It seems to me the reasonable solution to the as:Listen-spamming issue here. If you subscribed explicitly to get as:Listen then it is completely reasonable to expect your client to know how to handle it in a way that is not annoying to the end user
@darius @erincandescent It’s all just email subscriptions in my head, lol. Like in Github you can choose to be notified of comments, forks, etc. as you please. If LastFM added support for email notifications any time a friend scrobbled anything, and you subbed to that, well… hey, it’s your inbox, right?
@trwnh @darius I think personally I lean towards a pure firehose model. Send me everything you got and let my clients pull out the data they're interested in
In part because we're unlikely to ever agree on one exact axis of filtering
@erincandescent @darius I heavily dislike the firehose model and would be terrified if my email inbox submitted to the same philosophy.
@trwnh @darius I actually think this demonstrates a fundamental flaw in the email model
There are times you want to be able to do endpoint to endpoint but potentially automatic message exchanges, and email doesn't really have a mechanism for doing this
The straightforward example is my client noticing your S/MIME or GPG key is expiring and asking if there's a new one
@erincandescent @darius i think this could be solved by declaring specific endpoints for these things. no reason it should ever reach my inbox unless it's meant for my attention.
@trwnh @darius I guess that's where I think your inbox is your actors inbox but not necessarily "your" inbox
Things like Update and Delete activities aren't really for your attention; they're just for endpoint synchronisation
@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
@trwnh @darius you want more actors, I want less actors
This, obviously, means war :-)
@trwnh @darius more specifically if *I* have multiple actors I want to it be around multiple facets of myself, not dictated by technological constraints or similar
@darius @trwnh I don't even like that I need to have an alt. We have Google+ esque circles in the protocol, I should be asleep to use them
(And don't get me started on the fact that replies to my followers only posts get addressed to the replying person's followers)
@erincandescent @darius This! Let me create Collections that represent arbitrary subsets of my followers. Let me address them. Stupid sharedInbox makes this "inefficient", though.
@erincandescent @darius I will not stop until ActivityPub is a turing-complete computing platform
@trwnh @erincandescent turing completion considered harmful
@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
@darius @erincandescent actually isn't this more or less what spritely goblins is for
@trwnh @erincandescent dark magic that I leave to Christine
@erincandescent @darius I think I'll win the war because I have more actors on my side :P
@trwnh @erincandescent @darius neat! The https://github.com/evanp/bots-rodeo/ platform is supposed to do just that.
@erincandescent @darius @trwnh the fediverse in general could benefit from thinner servers and thicker clients, it would make all these interop discussions so much easier
@laurenshof @darius @trwnh ... Things I have been shouting for literally a decade!
@erincandescent @darius @trwnh right, yeah, i meant this as a i'm-shouting-with-you-in-agreement-post
@erincandescent @julian @mike @hongminhee @thisismissem @pfefferle @trwnh @michael @renchap In pump.io, we divided the inbox stream between "major" (new content, new shares) which is shown in a home timeline interface and "minor" (everything else) streams which are shown like notifications. Your scrobbles should be notifications and should be silenceable by the recipient.
@trwnh @thisismissem @pfefferle @hongminhee @julian @renchap @mike @michael icon, image can help too.
/cc @linos
@julian @renchap @pfefferle @mike @michael @hongminhee
Same for CastoPod: Mastodon was/is the reason they actually send the creation of a `Ǹote`, which essentially contains the summary and a to link of their well defined PodcastEpisode ActivityStreams object. In fact adding a new supported object type to Mastodon is a one-liner and I was a bit sad that not even a issue got opened. But I hope we can overcome such hurdles in the near future!
@julian An issue we have with redirecting the user to the original post is that it makes it very hard for the user to interact with the post. We still want to improve this (in 4.4?) but are still very short on resources.
We discussed changing the "read more" button to open a modal, and (is this a good idea?) supporting an AP attribute with an iframe suitable for embedding the content, and changing the show more button to open a modal with this iframe
@pfefferle @manton @samsethi @andypiper
@renchap@oisaur.com That is a valid concern. A basic tenet of growth hacking and increasing engagement is simply to not drive the user to another site.
There's an opposing viewpoint that states that you should trust your users enough for them to return on their own, hehe.
I know there's a strong desire to keep users on-platform, which is why I suggested using
target="_top"to open a new tab. I hope that's a good enough compromise, but ultimately it is up to the Mastodon team as to what works best.@julian This is totally not about growth hacking or engagement 🤔
Users see some content, click on it, then end up with a new UI, see a reply button, click on it, and are asked to create a new account, or to sign up (but not with their initial account). Our user testing (and many feedback) points that this is a very common issue with AP federation at the moment, even between Mastodon instances.
Not many people understand what is the federation and how to work around it
@renchap@oisaur.com
I am more than willing to admit that this is a complex issue that cannot be solved independently by one implementor. A user shouldn't have to think about how to navigate various ActivityPub implementations with respect to replying/liking, etc.
My apologies for assuming it was about growth hacking (which I still wouldn't begrudge you if it factored in, I think we all think about it a little.)
So let's set aside that for now and see if the content presentation can be improved just enough.
@julian I totally agree with @renchap that it is important to keep the user on the platform of his/her choice! I like the idea of having a better "read more" UX or maybe the lightbox idea.
But to have the best possible experience and to improve the engagement, you should not force the user to leave the platform.
Otherwise it feels very much like subscribing to an RSS-Feed with only excerpts, where you always have to leave the reader for reading the whole text!
@evan @julian @pfefferle @manton @renchap @andypiper @Gargron I 100% agree with Julian. We are new to AP development but very excited. I was surprised by the lack of AP vocab support in Mastodon given the AP vocab has not been updated since May 2017.
Being a podcast & music app we had hoped to use the LISTEN verb. Sadly we can't as there is no support? Equally we offer blogging and event ticketing in our platform, so using ANNOUNCE, ARTICLE and BUY verbs will hopefully work???
@samsethi so, I think you should just publish the activities that make sense for the problem domain, and we can worry about getting support for them by other platforms afterwards.
@evan sadly its chicken and egg. If we publish with the listen verb and no apps read/render it then. our users will ask why their activity was not published. So we are forced to use the lowest common denominator aka note so it is read now by AP clients. Very happy to experiment as I know we are a new use case.
@samsethi @evan this is why AP servers need to advertise what activities and objects they support, without this we'll almost never be able to use the full vocabulary, as everyone will choose the lowest common denominator for the platform with the most users.
@thisismissem @evan 100% agree but how?
@samsethi @evan I think this links to the various efforts: https://github.com/w3c/activitypub/issues/430
@samsethi here are the Object-Types that are supported and that will be transformed into a `Note` https://github.com/mastodon/mastodon/blob/ca8e892c1abb91722c256030c83cabec8e3445ff/app/lib/activitypub/activity.rb#L9
@julian the cynicism in me tells me that they did that and haven't changed it yet so they don't "accidentally" send someone to a better Fediverse software.
Lots of Mastodon decisions seem very sus lately. The lack of moderation tools and the devs completely ignoring requests for them are the biggest concern.😔
If I remember correctly, Mastodon simply implemented a link to the source as the ‘solution’ for as:Article. This is not what users expect, it is not what the author had in mind, but it is probably considered ‘sufficient’ by Mastodon.
Mastodon shouldn't ‘adapt’ to other services either, but it should implement the AP standard properly. The way it has been handled so far, it feels rather arrogant.
@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
@laurenshof@indieweb.social 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:Forkactivity, and therefore no support *sheds tear*@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. :grimacing:
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
This will only work for as:public 🤔
@julian // There is no target="_top", only target="_blank". Well, you can use _top, but it is just a normal name and any new link opened will replace a page previously opened, which will likely be not what a user wanted.
Just coming across this now, hello everyone -- I wanted to say that Hometown has implemented what @julian proposes in the OP for its entire existence, since about 2019. It's worked quite well!
https://github.com/hometown-fork/hometown/wiki/More-content-types
<img alt="Example of the feature working" src="https://camo.githubusercontent.com/2d080ff1a9c00b858458919923ad8c0ab32c7fc958cd3f963f3239d359bb7a28/68747470733a2f2f74696e7973756276657273696f6e732e636f6d2f706963732f686f6d65746f776e2d61727469636c652e676966">
@dariusk @darius@friend.camp Thanks for sharing this, I think it's fantastic that this is already adopted in a Mastodon fork.
May I ask whether there have been attempts in the past to get these changes back upstream to Mastodon?
cc @renchap@oisaur.com
@julian This was ~4 years ago but I asked someone on the team (I forget who) if it would be a welcome PR and I was told that it probably wouldn't be, so I didn't make the PR.
Of course that was a long time ago! Also of note, this was completely and totally a hack and I don't think my actual implementation is what I would want to put upstream at this point. What's more interesting is that it hasn't been the cause of any UI concerns; basically what you postulate above, that the "hide long content behind a cut" functionality pretty much solves the problem, is true.