Piece by piece, we're connecting #Bandwagon to every corner of the open web.
Today, we're improving how links to your songs and albums display when someone shares them on Mastodon, Facebook, and others. It's a small thing, but immensely valuable to the social web.
As an example, here's an album I've been listening to on Bandwagon.fm: https://bandwagon.fm/671667a8d7963fa9c589401e
The deeper I dig into the #Fediverse, the more I realize that we aren't building a "federated" group of individual apps. It's a single, integrated system. Something like a digital hive-mind, and everything is connected.
Those once isolated websites and services are like individual cells in the body whole, making connections between (API's, protocols, etc) even more important than the individuals themselves.
@benpate this was how folks spoke of RSS 25 years ago, but it all fizzled out
Yup. I was there 25 years ago. We were all very excited.
Then FB cracked the social media code and Google killed the only RSS Reader anyone used.
Modern social networks are better than RSS because you can post AND follow in one place. RSS was just read-only, without “likes” and “shares.”
I feel that same excitement now about the Fediverse. And I think we have a chance to hold off the VC firms if.. IF we can make a single distributed ecosystem that performs as well as big tech.
@benpate yes, a global social network where people connect like pages connect on the internet, regardless of the service you use to build your website. It’s a significant new layer to the web and will enable new business and services, way beyond the social networks you see now.
@marci Yeah, that’s the whole idea of the Fediverse now, right?
But there are too many gaps between servers, so it doesn’t yet perform like a single entity.
Say you find a cool website and you want to follow it. Getting back to your Mastodon instance (or wherever) is pretty messy. Double that if you’re on mobile.
There are lots of things like this we can do better if we imagine Fediverse UX as a single organism.
It’ll make the difference in the battle with FB and Xitter.
There are lots of things like this we can do better if we imagine Fediverse UX as a single organism.
@benpate @marci i think that when you'll make it a single entity you'll get something like gmail or fb. the 'convenience' must not have the final word. we people are messy and that's ok. not that everything must be very difficult, inaccessible or ugly, but diversity of multitudes must not be silenced either. there must be a balance, and scaling everything into one network or app or site or single button is a dead end.
@benpate This object shouldn't have actor
property. It can only appear on activities: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-actor
@silverpill Thank you! I’ll double check the ActivityStream data.
@benpate Do you really need two types there? I know, technically array is a valid value for "type", but a single type can be understood by more services.
(I think Article
is a good choice for representing music album.)
@silverpill @benpate in fairness there's already a schema.org document for music releases:
https://schema.org/MusicRelease
Bandcamp uses them on album pages.
@silverpill @mariusor This is an excellent resource. Thank you! Fun Fedi keeps getting better and better.
I think I was trying to follow FunkWhale’s model, to be as compatible with it as possible. But the two object types probably will be more trouble than they’re worth.
I’d love to use these definitions from schema.org, but I don’t think they’re supported anywhere on the Fediverse, are they? If the goal is compatibility, this might be a footgun.
@benpate @silverpill they probably aren't supported in the fediverse because (almost*)nobody has a valid JSON-LD implementation. But they are JSON-LD compatible.
This is an excellent resource. Thank you! Fun Fedi keeps getting better and better.
Thanks.
@benpate @mariusor Most services have hard-coded lists of supported types, and will drop any object with unusual type
like MusicRelease
(see FunFedi data, only Mitra accepts objects with arbitrary types, because it uses duck typing).
>I think I was trying to follow FunkWhale’s model, to be as compatible with it as possible. But the two object types probably will be more trouble than they’re worth.
Can it handle [Album, Article]
? If so, that might be a good argument in favor of that value.
Their docs describe Album object, but say type should be a string.
@silverpill @mariusor I haven’t gotten far enough to test FunkWhale’s object type handling, so I couldn’t say for sure.
All of this is just a perfect example of the issues in our other “ActivityPub Improvements” thread.
The JSON-LD dream of “everything can be anything” sounds great, but nobody can actually use it. At the end of the day, RDF data doesn’t cut it as a UI. We’ll all be better off when we go back to some kind of structured schema and move forward.
I think duck typing is great. Articles can be identified by name
and content
properties. Music albums can be identified by other properties, e.g. artists
and tracks
. Now you can use all these properties in one object. Music services will display it as a music album and blogs will display it as a post, interoperability is easier that way.
I have a document where I collect ideas like this one, as well as best practices and common-but-undocumented requirements:
https://codeberg.org/silverpill/feps/src/branch/main/d85d/fep-d85d.md#types
Schemas could be useful too, I've been exploring this idea as well:
https://codeberg.org/silverpill/feps/src/branch/main/d85d/schemas/activity.schema.json
Yes, duck typing is probably the way to go, along with one or two “requested”, or “recommended” UIs..
I’ve been re-exploring oEmbed recently, and I think its designers were on to something good:
1) provide semantically meaningful types (unlike AP)
2) add metadata to documents (we could go further here)
3) provide optional custom layouts for those who want it.
@benpate that’s fantastic. Going to check it out now.