Cactus Comments: Federated web comments based on Matrix protocol
cactus.chat
cactus.chat
That being said, I would imagine it would be done the same way as an automod type bot for any Matrix room. You'd probably have to implement it yourself though.
Edit: That being said, I don't like the idea of automatic moderation. For small scale blogs, maybe just a manual approval of comments would be worthwhile.
I first encountered 'hate speech' as a wide eyed teenager in the 1990s on a gaming IRC room that I hung out in. Somehow my ethnic background came out, and it was bizarre: the entire room either turned against me with racist hate speech, adding that they knew where I lived based on my ip (didn't think this was possible, but then didn't know anyone to ask if it was) and would come beat me up or worse. Or they just went silent and wouldn't stand up for me. I asked the moderators to help and I don't think they ever replied; certainly they never did anything. It was terrifying, and it made me clock out of IRC and online gaming communities for good.
So I wonder, to those who downvote someone asking about moderating (posts on your own blog!) or just consider hate speech as a term to be 'tedius' : have you ever experienced it yourself?
I didn't downvote and i'm certainly in favor of strong moderation. However automated filters worry me as they have shown time and time again that regexes aren't as sharp as human moderators.
For recent discussions about that on Lemmy, a federated Reddit replacement based on ActivityPub: https://lemmy.ml/post/55323 https://lemmy.ml/post/55143
Why? I think it's quite a useful term that's worthy of discussion from philosophical and legal perspectives. It pretty quickly identifies a range of related behaviors. But I am interested if you have less 'tedious' terms that describe the same thing.
Too bad cactus doesn't work without JavaScript. Would it be possible in the future to support submitting a comment via simple HTML form for older/slower clients? A related annoying detail, '?' key is hijacked by JavaScript so it's impossible to type it in the comment box ;-)
Thanks for this demo i'm excited for the future of federated comments
Making Cactus Comments work without javascript would require a backend server. Right now, the frontend is actually just a special-purpose Matrix client that interacts directly with Matrix homeservers.
How hard would it be to add non-Matrix accounts to this service?
Unfortunately Facebook shut down the brid.gy gateway a few years ago, but other silos still interoperate fine.
https://github.com/MetaMask/eth-phishing-detect/blob/master/...
>Ethereum Phishing Detection
>This domain is currently on the MetaMask domain warning list. This means that based on information available to us, MetaMask believes this domain could currently compromise your security and, as an added safety feature, MetaMask has restricted access to the site. To override this, please read the rest of this warning for instructions on how to continue at your own risk.That's its strength.
Core to many usecases, many eyes, many industries' backing.
Well more so than other federated protocols. matrix has a strong emphasis on resistance to censorship and network splits, at the price of metadata leakage. In contrast, AP/XMPP assume every server is a tiny kingdom (no content is owned by more than one server). matrix usecase is really cool but could have been built on top of existing federated protocols without reinventing a new ecosystem.
Can't wait for proper interoperability between the three big federated networks (Matrix, XMPP, ActivityPub). The previous discussion on HN about this topic didn't go very far: https://news.ycombinator.com/item?id=26279906
I was reacting to matrix being "not meant to be any one thing". I explicitly recall matrix being marketed by the community (maybe not the devs themselves) as a modern, censorship-resilient IRC replacement that fitted in a short (single?) specification and intentionally avoided the extensibility (and associated implementation/interop failures) of the XMPP protocol.
When i say matrix is a more specific use-case than other federated protocols, i mean that decentralized rooms can be implemented as a consensus-reaching algorithm on top of any federated protocol, and that's in fact what matrix servers are doing under the hood. But supporting the usecase of least-metadata-leakage in a protocol designed for sharing state across many actors is arguably trickier.
For example, i believe matrix doesn't currently support per-room nicknames which don't reveal your public address to all members of the room (only to chatroom admins for ban purposes). matrix has very interesting developments with or without this specific feature, but i was highlighting that matrix is not more generic/agnostic than other federation protocols (just like XMPP isn't a "universal" protocol either).
Like i'm very interested in matrix P2P ecosystem there's some really amazing stuff being developed there (pinecone), but i must say the entire matrix selling pitch is very similar to the selling pitch of XMPP more than a decade ago: "a universal bridgeable messenger". Regarding the P2P example, XMPP had offline-first "zeroconf" federation (XEP-0174) drafted in 2006. Despite being far less advanced than modern matrix P2P, it was already very similar in spirit.
So my central point i guess, is not that one protocol is better than the other. They all have very strong pros and cons depending on the actual usecase. Different users, or same users across different contexts/activities may prefer one technology or the other. My point is i believe it is our responsibility as technologists to ease their life and standardize things for more interoperability so users can have a choice between "the federated networks" and "centralized silos" instead of having a choice between "centralized silos" and "tiny federated islands that mostly don't talk to one another", adjusting the balance of power in our favor which is in the direct interest of everyone involved except the corporate silicon valley sociopaths.
Cory Doctorow's latest talks have pretty compelling arguments for interoperability if you have some time to spare.
I do concede that XMPP is not the new shiny, but it is very far from dead.
It powers more things than you realise, a few are listed at https://xmpp.org/uses/
There is healthy growth in server count: https://blog.prosody.im/2020-retrospective/
Development is very active, across a diverse range of projects: https://xmpp.org/category/newsletter.html
Some clients/servers are unfortunately unmaintained and the XMPP Standards Foundation has a neutral position which prevents it from advertising specific clients which have good UX and modern features. But modern clients like Conversations, Dino, Siskin and Gajim are certainly good messengers with hardware and feature support i haven't seen in other ecosystems (client & server side low resource requirements, good Tor support client, and vast plugin ecosystems) though there's some dearly-missed functionality (eg. groups of chatrooms like matrix spaces).
If you're curious about interesting developments, libervia (ex salut-à-toi) is the only federated piece of software i know that is selfhosting its own development (forge). Tickets and merge requests for libervia are done via libervia itself. They've been doing that for almost 3 years now, using mercurial as a backend but implemented in a way that other DVCS backends can be supported. See my blogpost about decentralized forging for more context on that https://staticadventures.netlib.re/blog/decentralized-forge/