Thank you! I’ve been thinking about it a lot, and I think it could be used to solve a bunch of different problems, like importing stuff from other networks, and having everything ready to go before you join an instance.

There’s some UX questions that have to be figured out, the last thing I want is some super-cluttered design that asks for a million different options. Also, platforms would need to provide some necessary APIs (for registration and data import) to make it fully useable.

My main critique is just that, within the Mastodon side of the Fediverse, the design is highly misleading about what the feature does. It resembles a normal DM feature, but the message addressing is purely handled by mentions in the message body.

Basically, it’s an antipattern, causing people to accidentally mention other people in what’s assumed to be a Direct Message. It’s less about privacy, more about poor telegraphing of side-effects.

I used to feel that way, but there’s so much crap on that timeline, especially when you’re on a bigger instance. I used to use it for the exact same thing, discovery. A lot of it is just noise to me now, though.

Well, no, this was just responding to a critique on UX shortcomings, and highlighting how different efforts could solve various problems.

It sounds more like you’re talking about one of my previous blog posts, where I was talking about a super-flexible frontend that’s basically a pagebuilder. Make no mistake, I would love to see custom profile music and radios! And I agree that accessibility needs to be way better!

Posting from another thread:

Her comments cover everything from “trans women are mostly autistic boys who have been gaslit” to “there are only two sexes” to “trans people are unfit to play in their gender’s sport.” However, there are far worse comments floating around out there that talk about genital mutilation and all kinds of other heinous shit.

It wasn’t just “I have a different opinion, we can agree to disagree”, it was full-fledged unhinged stuff that all followed the TERF playbook.

It’s basically an open source, federated clone of GrooveShark, which was kind of like Plex but just for music.

Lukewarm take at best. It’s cool if it’s not for you personally, but a lot of people use it, love it, and benefit from it.

I think the stuff that Loops is building out could eventually become a standard feature that a lot of Fediverse platforms optionally offer. That kind of interop for the people that want it is frankly a win.

We Distribute hosts a version of their podcast, Decentered, on PeerTube: https://spectra.video/c/decentered_podcast

I don’t disagree, but again, the listed platforms are launch partners who have opted to publicly support the organization on Day 1. It very well could be that they reached out to Lemmy and other projects, and didn’t hear anything back.

The list of shout-outs in the main announcement pertains to projects who have partnered with the SWF, and intend to support it and collaborate.

It’s also worth keeping in mind that there are more than 80 different platforms in varying states of development. Yeah, Lemmy is one of the bigger ones, and OG Threadiverse, but the list of platforms to name is absurdly long at this point. I think it makes sense for them to focus on the protocol, and immediate partners.

The connotation has more to do with the long tradition of Pirate Radio, not a bunch of random CIA stuff.

Interesting insights!

The original reason we started this was actually for our own development. Our site includes project icons and colors in dedicated tags, which link to dedicated topic hubs. As we started working on this, we realized that there wasn’t a really good resource, and that we would have to build something from scratch.

Those symbols that you see are typically Unicode. Icon fonts are generally a CSS hack, in that a collection of SVGs have been converted into a font. The Unicode strings can be thought of as “letters” for that font. You’re absolutely right that there are accessibility limitations, but the tradeoff is that people get an easy way to use their favorite project icons to represent where they are on the Web.

At the very least, you won’t have any uBO problems with our site, as the font is incorporated directly into the theme we’re using. We’ll likely explore making a WordPress plugin next, so people can add these to their profiles and menus and other places.

I agree with you in spirit, but some of this stuff needs to be spelled out for people interested in the space. Not every person that builds for ActivityPub is overly aware of technical and cultural expectations. A lot of that knowledge exists in someone’s head somewhere, and the Fediverse does a pretty poor job of making assumptions about those people.

Case in point: one of the stories linked in the piece discusses a guy that implemented ActivityPub on his own, got it to work, but didn’t know enough about the space. People thought it was a crawler, turns out it was a blogging platform, but the drama ignited to the point that someone remote-loaded CSAM on the dude’s server using Webfinger. Dude was in Germany, and could have gone to prison simply for having it.

We can’t hold two contradictory positions, where we invite people to build for this space, and then gaslight them over not knowing things that nobody told them about. More than ever, we need quality resources to help devs figure this stuff out early on. This article is one small step in service to that.

Honestly, self-hosting is kind of the way to go, so long as you stay on top of your backups and storage. There are a lot of Object Storage providers out there that offer reliable storage for cheap, it’s a good investment if you plan on uploading somewhat frequently.

It’s actually not too bad to run, it’s just that my community instance has grown a lot, and is close to four years old at this point. Issues crop up, I mostly wrote this guide to share some insights on how I deal with things.

I can’t tell whether this is serious or sarcastic 😅

As far as the “global square” part of the equation is concerned: yeah, you’re right! A firehose of public statuses requires indexing to work, as a basic foundational premise.

However, there’s nothing preventing someone from standing up a PDS, opting out of the firehose / big graph service, and instead leaning on federation between individual PDSes. I’m not saying it would necessarily be a common use-case, but it’s definitely not impossible.

It’s a different approach with different ideas. It uses open protocols, focuses on data and account portability, and incorporates peer-to-peer concepts in its architecture. The vision behind Bluesky is to build a global square with these concepts.

I definitely wish they would’ve extended ActivityPub and collaborated on the wider network, but I kind of understand wanting to start from scratch and not get involved with the cultural debt Mastodon brought to the network.

Misskey is a little bit odd, in the sense that there’s constantly new forks in various stages of development. New forks emerge just as quickly as old ones die off.

It may be that the frontend and backend both being written in one language helps make the system easier to hack on. I can’t say for sure. What’s weird is that some of these forks go in really odd directions, like rewriting the whole backend in a different programming language.

The other thing is that, despite their proliferation, the effort is somewhat fragmented into all of these little projects. I’m not sure how viable any of these forks are in the long term.

Thank you for these insights!

Yeah, aside from developer muscle, an effort like this requires deep knowledge of the existing system. Or, failing that, a commitment to learning it.

It’s also not something that can be done as a side project, if it hopes to compete with the main project to the point of replacing it. Something like that requires an ungodly amount of effort and dedication. Someone would have to commit years of their life to solely working on that.

It’s an interesting and frustrating problem. I think there are three potential ways forward, but they’re both flawed:

1. Quasi-Centralization: a project like Mastodon or a vetted Non-Profit entity operates a high-concurrency server whose sole purpose is to cache link metadata and Images. Servers initially pull preview data from that, instead of the direct page.

2. We find a way to do this in some zero-trust peer-to-peer way, where multiple servers compare their copies of the same data. Whatever doesn’t match ends up not being used.

3. Servers cache link metadata and previews locally with a minimal amount of requests; any boost or reshare only reflects a proxied local preview of that link. Instead of doing this on a per-view or per-user basis, it’s simply per-instance.

I honestly think the third option might be the least destructive, even if it’s not as efficient as it could be.