I have created the world's worst IRC bot framework: a persistent JavaScript REPL where anyone in the channel can do anything they want

We're just incrementally building up bot convenience features now in the most fragile and stupid context imaginable


<sircmpwn> .js on(/^I hate (.*)(\w|$)/, (msg, thing) => msg.reply(`yeah, fuck ${thing}!`)
<bot> => 7
<sircmpwn> I hate ARM
<bot> yeah, fuck ARM!

@sir oh neat, have fun reinventing all the IRC bot disasters of the past! (no spoilers, people!)

@riking this channel already has 8 bots, we're well into the disaster

@sir @riking Back in my day, I only made bots that posted ASCII dicks (both human and equine) whenever someone typed "cock"

@sir Is there a reason you hate ARM so much? I don't have much of an opinion, just curious

@sir this has already existed in ##javascript for awhile 🙂

@sir I'm just starting to read into it, but from what I understand if it's federated, servers will "push" whatever content to whoever wants to see it (just as regular ActivityPub use) (I'm not sure how familiar you are with ActivityPub).

This'll create a very similar experience to email I imagine, but at least it'll be more structured...

@indirection I was an early critic of forgefed and remain so now. I don't think we should be shoving everything into ActivityPub, I don't think the software development model/workflow it endorses is a good one, I don't want to create a separate network from the existing email network, and email is already doing this job and the tools they want could be built on top of it as easily as with ActivityPub

@sir again, I'm not sure how familiar you are with ActivityPub, but at least when I look at the big picture, it looks a lot like a new alternative to email.


* Usernames are essentially inboxes (even the protocol uses this term)
* Messages are sent to your server
* Content is saved on the server
* You can message multiple people
* You can literally cc people too (it's in the protocol)

Since AP is more structured, it opens doors to new, useful ways to use the information.

@sir All this to say, I think the concern "I don't want to create a separate network from the existing email network", may not be something to worry about much, when it turns out the functionality of both can be the same, right? At least that's what I believe anyway.

@indirection no, because the networks are mutually exclusive - you can't send an email to activitypub or vice versa. It creates a new *and separate* community. All just because everything looks like a nail when your hammer is activitypub. There's no good reason at all to cram git into AP

@sir Ok, I think maybe I don't understand what you've written.

> "You can't send an email to AP"
< Of course you can't send *an email* to AP, but what I mean is, the concept of inbox and outboxes and messages exist, just like in email. It's even defined using those terms.

> It creates a new *and separate* community
< If you mean AP as a whole does, well, yes, but the idea is everyone will eventually transition.

> There's no good reason to cram git
< So let's cram it into email?...

@indirection but it's *different*. The networks are *disconnected* and *cannot talk to one another*. Users must /choose/, and context switch between them.

git was designed to be used with email from the outset, it has built-in tools for working with git over email.

@indirection github-style browser-based git collaboration is an invention made up by github and has nothing to do with git, git is all email all the time baby

@sir ignoring git all together, decentralized project management is a perfect fit for ActivityPub, which is all any Git* really offers in the end (well, plus CI these days), wouldn't you agree?

I agree that exchanging git patches can happen in any way really, and yeah, I understand it was designed for email first 🙂

@sir yes, they must choose. As each day I use ActivityPub-based software, I see it supersedes email. It's just superior in every way. Show me an email "protocol" which can do not just private, but private and public messaging simultaneously 🙂

I mean if you think email is forever then ok, that's fine too. And I'll continue to use email as well until the scales tip.

@indirection it's called "email". You Cc a mailing list. Stop reinventing email but worse. It's horrible, and much, much, much worse, in all of the important ways like data
ownership and extensibility.

It's obvious to me that you have never actually collaborated over email at all, because you're demonstrating an ignorance of the norms and features of such a workflow. Maybe you should try it before you try to replace it.

@sir ...

Please, I'm not trying to attack anything. I'm just explaining how I'm seeing the similarities. I'm not reinventing anything.

Uh, no, I've collaborated over mailing lists many times.

This just means our perspectives right now are pretty disjoint. That's ok, let's fix this instead of just trying to jump to a conclusion. 🙂

Thinking about it a bit more, yeah ok, a mailing list does fit the bill. Software manages it, just as someone hosts an ActivityPub server...

@sir I think what I see as the comparison breaking apart is a mailing list doesn't have the advantage of the excellent event facilities ActivityPub offers which can be used in many ways.

I guess Usenet (?) was essentially social networking before it became popular? People mailing to certain lists about certain topics...

I guess a mailing list is also inherently centralized. There's no federation which happens between mailing lists normally, right? Sure it could be implemented.

@indirection what "excellent" features to which are you referring

@sir Ok, I can already see my choice of using the word excellent is probably going to backfire. I'm just putting emphasis on how useful the event system is.

Here's what I'm coming up with off the top of my head, I read the standard last week:

* Getting notified of events which happen in other places automatically
* Each piece of data is traceable because of JSON-LD
* Ability to block (can mailing lists do this?)
* Filters based on explicit object types

Events like what?

What do you want to trace and why?

At no point did you explain why this is desirable or how it relates to git, you just spouted bullet points off of the activitypub wikipedia page.

Mailing lists can be moderated and your MUA/MTA can filter further, and I guarantee you seive is more sophisticated than any AP implementation of blocking. Email has spent 30+ years figuring out how to block people.

Filtering based on explicit object types? Newsflash: email can be filtered, too.

*beats chest*

@sir 😆 Sure, sure.

Like I said, I'll continue to use email until the scales have tipped. For all I know that might mean I'm using email forever. 😎

@sir <_>

This is like arguing textual-based tools vs structural-based tools.

Overall I think this conversation proves to me even more how similar ActivityPub and email are.

Saying I'm spouting bullets points from Wikipedia... like what? Why?

I think you've made great points. Briefly: it relates to git because of how you pointed out git was designed for email, and that ActivityPub in my eyes looks like a great alternative to email coming, so ForgeFed seems like a great idea.

@indirection mailing lists are not centralized in the least, their fundamental design involves forwarding the email to everyone who is subscribed, which puts a copy of everything in their mail spool. And no one ever said that the subscribers can't be other mailing lists

@sir @indirection Worst is that the visibility scopes are mastodon bullshit slapped into email addressing. (pleroma has at least two workarounds to avoid leaks)
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!