Hi all.

Just to spam something me and others were working on :).

We work on an IRC client and, given that we use fossil for project management, we also wanted to use the fossil chat for it.

As part of this, we've built a bridge we use to connect to the fossil chat, given that we generally are on IRC already and we don't want to keep a web browser opened just for it.

How the bridge works is described here, it's also portable and, given that it uses stdin and stdout for communication, wrapping it around an inetd service make it work with any other IRC client (we've tested hexchat, but I believe other clients will just work, too).

The only thing that is a bit annoying, is how the fossil chat bot does not respect the "raw" parameter in the URL and the messages it posts contains HTML snippets that, in a normal text client, are a bit difficult to read.

Not that big of a deal thought, but it would be nice if the chat bot would send plain text, it possible, when "raw" messages are requested.

Cheers!

Not that big of a deal thought, but it would be nice if the chat bot would send plain text, it possible, when "raw" messages are requested.

We don't have a markdown-to-plain-text conversion or we'd probably already have added that capability to /chat. We had a guy working on an ncurses client for it for a while (the "raw" option was added specifically for that) and the markdown isn't terribly useful in such a client, but it's still human-readable.

Edit:

The only thing that is a bit annoying, is how the fossil chat bot does not respect the "raw" parameter in the URL ...

i can't reproduce that. In the html /chat client, the "toggle text mode" button uses that flag to collect the unparsed text. If you'll watch the network traffic when toggling that button (it becomes visible when you tap the header of a given message), you should see it passing you the unparsed markdown.

Hi Stephan

We don't have a markdown-to-plain-text conversion or we'd probably already have added that capability to /chat. We had a guy working on an ncurses client for it for a while (the "raw" option was added specifically for that) and the markdown isn't terribly useful in such a client, but it's still human-readable.

My bad, I wasn't clear. The raw parameter does what you expect if you send and receive messages as a normal, logged-in user. Only the built-in fossil chat bot is problematic

I can't reproduce that. In the html /chat client, the "toggle text mode" button uses that flag to collect the unparsed text. If you'll watch the network traffic when toggling that button (it becomes visible when you tap the header of a given message), you should see it passing you the unparsed markdown.

Let me send you an example of what I see on a normal IRC client. The following messages are from the logs of one of my chats (using the fossil to IRC bridge). The /chat-poll requests have the raw parameter set to 1.

This is a simple message sent from one client to another and it looks correct, in the sense that it's, in effect, raw:

2024-04-28T11:01:08 <absc>: IRC una volta che hai letto la RFC due o tre volte viene facile

This is what my client receives when the built-in fossil bot sends a message to the chat, to inform of a timeline change. In this case, /chat-poll also have the raw parameter set to 1:

2024-05-01T13:59:12 <irctk-robot>: Closed ticket <a href=\"/irctk/info/33722db398c5e6a4\"><span class=\"wikiTagCancelled\">[33722db398c5e6a4|33722db398]</span></a>: &lt;i&gt;Complete support for IRCv3&lt;/i&gt; plus 3 other changes\n

Mind that, we do not do any parsing of the received message, given that normal users chatting sees things just fine (as in the first example).

But for some reason, the notification robot sends some embedded HTML. If it was just markdown, I suppose it would be better. Unless the embedded HTML is considered markdown in this case.

But mind that, I'm more curious than anything else and, in the worst case, we could do a bit of parsing ourselves.

Only the built-in fossil chat bot is problematic

Ah, indeed. That user essentially just forwards stuff from the timeline, which is itself stored as html. There's no easy way around that.

I haven't checked. Is the format consistent? In that case, I suppose it would be easy for us to remove the HTML bits.

Otherwise, I believe we can live with the notifications as they are anyway.

Is the format consistent?

In the sense that it's always html (because that's what's saved in the timeline as new content arrives) and in the sense that that's highly unlikely to change because that behavior goes back to the beginning of time. Maybe in the hypothetical fossil v3.

It is possible that the precise content of specific event types may change over time, but it's very rare, and no new content types have been added since the forum artifacts were introduced 4 or 5(?) years ago.

In the sense that it's always html (because that's what's saved in the timeline as new content arrives) and in the sense that that's highly unlikely to change because that behavior goes back to the beginning of time. Maybe in the hypothetical fossil v3.

Ok, I'll try to see if I can find a solution around that.

Plain text as really plain not so necessary, as IRC clients support mIRC color codes for decades, with at least bold and underline supported in them.

Some time ago I made an IRC logger which logs given IRC channel to a fossil repo:

https://codeberg.org/cgenie/irc_logger

It stores 1 day of logs as a separate markdown file. The fossil web allows for easy hosting of the repo. And, as a plus, I use libfossil underneath to make the commits.