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.
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
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.
@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
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.
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
@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.
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
@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 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
@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
@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