Hacker News new | past | comments | ask | show | jobs | submit login

Sure, Mastodon doesn't implement the full ActivityPub spec [0]. They're still very much behind the effort though, it seems [1] (or at least they were in 2018).

I'm not a Mastodon developer, nor have I developed with it, but surely there are learnings there that could potentially be contributed back to the W3C to make ActivityPub better (including making it more rigorously spec'd).

The people at the W3C are not gods - they're human beings just like the rest of us. Why not get involved in the conversation there?

The only genuine reason I can think of to split away from the ActivityPub effort to build a completely different protocol would be if the W3C's working group on ActivityPub is filled with such toxic politics that it's impossible to make any progress on making the spec better. (That's been the only reason I could see in the past when I've been part of protocol standardization efforts).

Without evidence of that, however, I'd say that it's far better for the community to get involved in making the existing spec better. Robust debate (supported by evidence, such as that which Mastodon's built up) is incredibly valuable to the community as a whole.

Also, it's incredibly valuable from a political decentralization perspective to have as neutral a party as possible facilitating the standardization efforts, to minimize the risk of Big Tech shaping standards in ways that would suit them financially (and potentially against the interests of the average internet user).

[0] - https://activitypub.rocks/implementation-report/

[1] - https://blog.joinmastodon.org/2018/06/why-activitypub-is-the...




Sure, Mastodon doesn't implement the full ActivityPub spec [0]. They're still very much behind the effort though, it seems [1] (or at least they were in 2018).

Not only this, but they go against it in multiple places. How they've implemented 'summary' and the bizarre things they've done to create compatibility with Misskey (but not in an actually-compatible way, Misskey's had to patch their own solution every time) has made every implementation have to implement an against-spec trashfire.

I'm not a Mastodon developer, nor have I developed with it, but surely there are learnings there that could potentially be contributed back to the W3C to make ActivityPub better (including making it more rigorously spec'd).

Alternatively, the AP spec is fundamentally broken in many ways, and that effort would be better off going into a protocol like Secure Scuttlebutt (not a fan, but it's much better than AP) or Diaspora (also not a fan, but it's much better than AP).

The people at the W3C are not gods - they're human beings just like the rest of us. Why not get involved in the conversation there?

The only genuine reason I can think of to split away from the ActivityPub effort to build a completely different protocol would be if the W3C's working group on ActivityPub is filled with such toxic politics that it's impossible to make any progress on making the spec better. (That's been the only reason I could see in the past when I've been part of protocol standardization efforts).

Not only politics, but it's incredibly slow. Webber has written a post on how troublesome the standardization process was, though he doesn't go into just how bad it was:

https://dustycloud.org/blog/on-standards-divisions-collabora...

Without evidence of that, however, I'd say that it's far better for the community to get involved in making the existing spec better. Robust debate (supported by evidence, such as that which Mastodon's built up) is incredibly valuable to the community as a whole.

There are already existing specifications, none of them as bad as ActivityPub. I'm fully for going in one of those directions, but AP is more or less a failed experiment.

Also, it's incredibly valuable from a political decentralization perspective to have as neutral a party as possible facilitating the standardization efforts, to minimize the risk of Big Tech shaping standards in ways that would suit them financially (and potentially against the interests of the average internet user).

W3C is not neutral, and not only are they not neutral, but the RIAA and MPAA are people with enough sway to have messed up the entire web multiple times (see: making EME a standard).

A neutral party sounds great! The W3C should not get to be involved, however.


Hi, Chris Webber here. You're quoting my blogposts out of context.

Yes, the standardization process was a difficult one. Standards efforts often are, and social web ones especially. Nonetheless I think we did a good job.

The purpose of those posts is to ask people to stop fighting each other and try to work together; it feels highly ironic for you to quote them to increase division.


> W3C is not neutral, and not only are they not neutral, but the RIAA and MPAA are people with enough sway to have messed up the entire web multiple times (see: making EME a standard).

> A neutral party sounds great! The W3C should not get to be involved, however.

Perhaps I got lost along the way, but... we're still talking about Twitter here right?

Are you seriously calling out the W3C, an open but obviously flawed organisation, for finally capitulating on DRM, after huge public drama and well-documented opposition from within the W3C. DRM is something entities such as Twitter use as a matter of course; there is no public discourse, nor documentation.

This isn't even as basic as pots calling kettles black, any reservations one could have about W3C as an org are positively laughable when the alternative is a standard stewarded by a corporation with the size and influence of Twitter.


The point of that was to note that the W3C doesn't care about the user.

John Sullivan had a great tweet about this:

https://twitter.com/johns_FSF/status/909931688641400839

Fundamentally, the W3C does not work in the interest of the user, and shouldn't be trusted.

Get some of the Scuttlebutt guys or the Diaspora guys to contribute! Don't get the W3C, no one who's part of the W3C should have a say in anything.

Twitter making a standard would at least result in something not stupidly broken.


> Twitter making a standard would at least result in something not stupidly broken.

Agree with most of your comment, but I can't see where this is coming from. I would be shocked if any "standard" coming from Twitter would be anything but broken.

Again, you're saying W3C doesn't work in the interests of the user, but ignoring that Twitter works actively against the interest of the user.

W3C isn't ideal, but the alternative being discussed is devoid of any merit whatsoever.


I agree with the spirit of your comment, but:

The alternative being discussed is Twitter appointing a different neutral party: if they're bending to the W3C, they're already appointing a "neutral party" to do the work for them, the only difference is changing who they trust from another giant organization that's very clearly apathetic about user interests to one that does: the SSBC would be perfect, for example.


> Secure Scuttlebutt (not a fan, but it's much better than AP)

If you have any specific feedback about which improvements are most important to you, I'd love to hear it. It's hard to see things with fresh eyes after you've been working on them for a bit.


I actually think that the SSBC has done a fantastic job with it: the work that's been done is really impressive. I'm mostly just not a fan of the ground it's built on; the implementation itself is amazing, and the protocol is solid. I wish you good luck with it!

And to anyone unfamiliar, I recommend checking out the "Principles" section of the handbook; there's a lot of interesting stuff in it, and it proves that Scuttlebutt's really got the best culture/morality of any distributed network so far:

https://handbook.scuttlebutt.nz/principles/


A while back, I came across this message:

https://news.ycombinator.com/item?id=16880060

Is this accurate currently? Its a turn off.


Yeah, none of us are very happy about that.

It's a quirk of the main feed encoding type, but there are other feed types (e.g. Gabby-Grove) that are major improvements. Right now the main hurdle is just adding support for more feed types to the major clients, which is something I'm actively working on.


Thank you for responding. I wish your project well.


Not op but would like to comment on this:

SSB is great; I'm not sure if others would agree, but while I think it has a lot of problems, none seem inherent (i.e. while they mightn't necessarily be easy to fix, they wouldn't involve any major architectural overhauls or scratch rethinks; what's there is conceptually sound).

The main issue for me is performance and resource usage, which is tricky since a lot of the traditional solutions to perf/resource challenges are cloud-based, which would erode ssb's value. Thinking about SSB on older recycled or embedded systems, etc. is hard.

The other is NIH; this is definitely something I feel the community is acutely aware of however; I recall seeing discussions of parallel implementations in Kafka, etc. years ago. I haven't kept up with recent development though.


The performance problem is hard, but we have lots of active experiments that I'm optimistic about. Implementations in Golang and Rust, a handful of great database experiments (even simple stuff like Sqlite), and a bunch of people who are actively using SSB on low-resource devices daily. The Manyverse app in particular runs on Android devices, which are going to be very resource-constrained when compared to most computers.

The NIH problem is hard, but I think we're moving in the right direction.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: