Support CW1 CTCP

[SoniEx2]

https://github.com/SoniEx2/CTCP-S/issues/13

(Yes, I actually use this on normal IRC. Most ppl I use this around already use rot13, anyway, so it's not a big deal for them to read it. Ofc, they never bother to send the CTCPs.)

[kensanata]

Shouldn’t these be features of the IRC client? This, and any other features like Morse encoding and whatever else we used to implement on top of IRC.

[SoniEx2]

Oh my IRC client supports this, but the bridge should parse and emit CW1s for toots with CWs.

Posting with CW, on my client, would be as simple as, say, /cw "post trans, mh-" today's a dysphoria day I guess. This would produce a toot with CW "trans, mh-" and content "today's a dysphoria day I guess".

[kensanata]

I’m afraid I don’t understand how this is going to work and how this is going to affect since I don’t have a conforming IRC client. At the moment I suspect that this is something I wouldn’t want to enable by default. If you contribute code that contains a setting that you can switch on, then perhaps?

[SoniEx2]

It gracefully falls back to plain old rot13, even clients without support won't see the hidden text by default unless they (manually) un-rot13 it.

Actually, mastodon CWs started as rot13, so this is just going full circle!

(How do you currently handle incoming CWs?)

[kensanata]

CWs are simply printed. If I remember correctly it’s: “[content warning] NSFW text text text.”

[SoniEx2]

uh, yeah, that's... bad.

[SoniEx2]

While working on this I found a few issues:

• Where does bitlbee do nicknames? It seems to add _ to nicks sometimes, but I have no idea how it does that. I need to take that into account when doing word_wrap so the CTCP doesn't cut off.
• Well that's the main issue really. Everything else works wonderfully! Well, except the reference implementation script - it has a minor bug. :p

[kensanata]

The nick names are connected by the Bitlbee framework. We just send them a “hint”, the nickname we would like to get.

[SoniEx2]

I can work with that, but I do need to know if there's a way to fetch the real nick?

Oh I remember now. There was also an issue with messages with timestamps on them. Why do some messages have timestamps on them? Anyway, I would like to figure those out too.

[dequis]

Worth noting that this CTCP was invented by soni and no client supports this out of the box.

[SoniEx2]

That has already been noted in the OP (it links to something I wrote). It's still a significant quality of life improvement over auto-opening CWs.

(Some ppl just try to destroy things others build for no good reason. Adding this CTCP breaks literally nothing, and is perfectly compatible with every other existing IRC extension.)

[kensanata]

I'm not sure what you mean by "destroy". The critical comment by @dequis? It seems like a very appropriate comment. It wasn't entirely clear to me, for example. Looking at the code, here's what I think would be cool:

1. We need an option to enable or disable the feature; I see that there's preparations for no_ctcp but it still needs setting up in mastodon_init and mastodon_flags_t, I think.
2. I think no variable should start with "no" so I'd be best if the option were called something like ctcp_cw1 and be disabled by default (but see the next point).
3. I'm not sure whether anybody would appreciate a simple rot13 implementation? Perhaps? As I said, I'm happy just printing stuff in plain text after a warning. A simple rot13 implementation would be what we now have but instead of using \001 and all that, just write “[content warning] NSFW ROT13 to read: grkg grkg grkg.” We could enable this if we used a different option: content_warning with the value plain (the default, just print it), rot13 (what I just wrote), cw1 (what @SoniEx2 proposed).
4. I'm not sure what the comment "add a newline at the start because that makes word wrap a lot easier (and because it matches the web UI better)" means: is it going to add newlines where there are none? I think this would be unfortunate. Shouldn't line wrapping be something the client does? Every line gets translated to a separate line in my IRC clients, so I try not to touch anything, there.
5. I think the merge request should go to the develop branch, not master.

[SoniEx2]

Okay so bitlbee does a lot of word_wrap internally (to not go over IRC character limits or something) and I have to deal with that so it doesn't cut off the CTCPs. I'm just adding space for the CTCPs, and it's easier by having a newline between the CW hint and the hidden text.

The web UI puts a newline between the content warning and the hidden text. When you click "show more" it doesn't appear in front of the "show more", but rather on a new line.

[kensanata]

Hm. I hadn't even noticed. I'll be happy to just see how it goes.

[kensanata]

As for line wrapping in general, I've noticed that my current code must have a problem because when I post long stuff and it gets echoed back, I sometimes see that something gets cut off, so perhaps you've noticed the bug which I just ignored for a while, now.

[SoniEx2]

I'll look into tweaking the other stuff, tho, thanks

[SoniEx2]

what's mastodon_flags_t? I'm not sure how to add the setting.

[kensanata]

Oops, forget that. I think this is enough: in mastodon_init you set the default value, and then you can retrieve it using set_getstr(&ic->acc->set, "content_warning") or whatever. If you wanted to go even further (not sure whether that's required), then you'd add a new member to mastodon_data and set it, and then you could access it from wherever md is available. As a user, in your control channel, use account mastodon set to see the settings available (unless they have the hidden flag) and change them accordingly.

[SoniEx2]

I can't access that from mastodon_xt_get_status? I'm not sure how I'm supposed to do this.

[kensanata]

You should be able to access it it because it includes bitlbee.h which includes set.h. You didn't specify the error. My guess is that you don't have access to ic or md deep in mastodon_xt_get_status? Yeah, you would have to pass something down. I'm starting to think that you should add a member to mastodon_data and then you can pass md down to mastodon_xt_get_status.

[kensanata]

I think pull request #27 handled most of the infrastructure. Thus, hide_sensitive can now be changed to a string and thus we could have true, false, rot13 and cw1 as options, for example.

[SoniEx2]

If you ever add default CWs for replies (aka replies that inherit the CW), the edge_case of #28 can be used to explicitly remove them.