I don't want another Twitter-but-reinvented. I want a Mastodon-interoperable "profile" to be enshrined in a standard that projects currently focused on compatible ActivityPub-based client/server implementations agree to support because it's a good compromise that allows people to participate with nothing more than the ability to publish a static site.
ActivityPub is so poorly/vaguely specified that basically every real world implementation follows what Mastodon does, so good luck with trying to get what you're after without being at least indirectly dependent on the decisions of yet another Twitter clone.
> good luck with trying to get what you're after without being at least indirectly dependent on the decisions of yet another Twitter clone
Not what I meant. The correct way to read what I wrote is with emphasis on "another Twitter-but-reinvented".
We already have have a Twitter-but-reinvented (Mastodon, and Mastodon-interoperable ActivityPub clients/servers). And people actually use it—which is the hard part of working on any kind of "social" gewgaw.
To think that we should throw that out and use twtxt or something like it would be to screw up bad. ActivityPub is better at being RSS-/Atom-like in its ability to convey structure than twtxt is, anyway. What's left is slicing it up, fusing the gaps and some now-necessary pieces with epoxy, and saying, "Here's the 'static' profile; you can look forward to support for this in Mastodon 4.0 [and everything else that tries to be interoperable]."
Yep. It was the same before Mastodon, with the predecessor of ActivityPub, et al. People had to "do whatever StatusNet/GNUSocial is doing". Even the code examples in the specs themselves were unable to interoperate with any instance whatsoever.
ActivityPub is supposed to be a generic feed format but in practice it's used mostly for Twitter clones so none of its non-Twitter vocabulary or flows have ever been developed.
The mechanism used to actually service publication requests from the person controlling the node is orthogonal to doing the design work to specify the thing and the political/social aspect of getting people to agree to support/adopt it. So, in a word, no.
(Side note: any design that necessarily depended on GitHub Actions or something with equivalent power would be a failure on the goals I've outlined.)
I don't want another Twitter-but-reinvented. I want a Mastodon-interoperable "profile" to be enshrined in a standard that projects currently focused on compatible ActivityPub-based client/server implementations agree to support because it's a good compromise that allows people to participate with nothing more than the ability to publish a static site.
ActivityPub is so poorly/vaguely specified that basically every real world implementation follows what Mastodon does, so good luck with trying to get what you're after without being at least indirectly dependent on the decisions of yet another Twitter clone.
> good luck with trying to get what you're after without being at least indirectly dependent on the decisions of yet another Twitter clone
Not what I meant. The correct way to read what I wrote is with emphasis on "another Twitter-but-reinvented".
We already have have a Twitter-but-reinvented (Mastodon, and Mastodon-interoperable ActivityPub clients/servers). And people actually use it—which is the hard part of working on any kind of "social" gewgaw.
To think that we should throw that out and use twtxt or something like it would be to screw up bad. ActivityPub is better at being RSS-/Atom-like in its ability to convey structure than twtxt is, anyway. What's left is slicing it up, fusing the gaps and some now-necessary pieces with epoxy, and saying, "Here's the 'static' profile; you can look forward to support for this in Mastodon 4.0 [and everything else that tries to be interoperable]."
Yep. It was the same before Mastodon, with the predecessor of ActivityPub, et al. People had to "do whatever StatusNet/GNUSocial is doing". Even the code examples in the specs themselves were unable to interoperate with any instance whatsoever.
ActivityPub is supposed to be a generic feed format but in practice it's used mostly for Twitter clones so none of its non-Twitter vocabulary or flows have ever been developed.
do you think what you're envisioning can be bootstrapped through github actions?
The mechanism used to actually service publication requests from the person controlling the node is orthogonal to doing the design work to specify the thing and the political/social aspect of getting people to agree to support/adopt it. So, in a word, no.
(Side note: any design that necessarily depended on GitHub Actions or something with equivalent power would be a failure on the goals I've outlined.)
3 replies →