mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

373K
active users

Ben Pate 🤘🏻

Piece by piece, we're connecting 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: bandwagon.fm/671667a8d7963fa9c

Bandwagon.fmIn an Unknown Place

The deeper I dig into the , 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

@danbri there was no technical avenue from RSS to what @benpate describes here. Whether today’s fediverse has such an avenue remains to be seen, but it can go a whole lot further in that direction imho.

@danbri

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.

@Ben Pate 🤘🏻
There are lots of things like this we can do better if we imagine Fediverse UX as a single organism.

The Fediverse is way too diverse for that. It isn't just Mastodon and Mastodon add-ons.

On the one end of the Fediverse, there's Mastodon. On the other end, there are Hubzilla, (streams) and Forte which are very, very much not Mastodon. They work entirely differently from Mastodon. And that's actually good. The Hubzilla devs and the (streams) and Forte dev even mostly refuse to adopt non-standard Mastodon stuff, much less make them more like Mastodon in general.

So you have Fediverse devs who develop new stuff for the Fediverse, but they only build it to interact with Mastodon. And then they're completely confused if something comes along and tries to interact with what they develop, but it doesn't work as intended because that something happens to be Hubzilla or (streams) or maybe even only Friendica.

Now, it's tempting to demand that everything in the Fediverse that is neither Mastodon nor built against Mastodon be made more like Mastodon. Including server apps that predate Mastodon and have a wholly different focus from Mastodon (Friendica is a Facebook alternative that's 5½ years older than Mastodon, and Hubzilla is a Friendica fork and a Facebook-alternative-plus-social-CMS that's still ten months older than Mastodon), and including server apps that can be traced back to these.

Well, if it's justified to ask something that works entirely differently from Mastodon by purpose, and that had been around for quite a while when Mastodon was launched, to become more like Mastodon, then I can ask why Mastodon and everything else doesn't become more like Forte. Conversation containers (which means that Mastodon would have to introduce conversations in the first place), full HTML rendering support, fine-grained permissions, nomadic identity etc.

CC: @Marci McCue

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse
hub.netzgemeinde.euNetzgemeinde/Hubzilla

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

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

@mariusor @benpate My software can handle it, but Mastodon/Pleroma/Misskey can't, as far as I know. So if wider interop is desirable it would be better to use Article.

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

docs.funkwhale.audioFunkwhale federation — funkwhale 1.4.0 documentation

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

@benpate @mariusor

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

Summary card of repository silverpill/feps
Codeberg.orgfeps/d85d/fep-d85d.md at mainfeps - My FEPs

@mariusor @silverpill

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.