Thank you for the report!

I have not tried out, what will happen if you delete such a message by accessing the table directly - deleting via the chat gui does more than removing the line from the table...

It's safe to delete chat messages - they'll simply disappear from the chat history. When the GUI deletes a chat message it does 2 things:

1. Removes the message record.

2. Inserts a new message which tells all clients which are currently polling that they should remove that message from their UI. Chat clients which connect later will not see the removed record and will simply skip over this pseudo-message because they don't have the deleted message locally.

The crash is resolved now in trunk. Posts made by "nobody" still have no name in the db, but the fix was to gracefully handle that case and not step on a NULL pointer. i chose not to automatically attribute all unnamed posts to "nobody" because the chat system is not really intended to be used by that pseudo-user. That decision is up for debate/reconsideration.

However, this change will have a side effect which you are not expecting: the chat client treats messages with no user name as system-level notifications, so any messages you post as "nobody" will be listed in the client with the name "notification".

Thank you for the quick fix and reply.

1. Removes the message record.

2. Inserts a new message which tells all clients which are currently polling that they should remove that message from their UI. Chat clients which connect later will not see the removed record and will simply skip over this pseudo-message because they don't have the deleted message locally.

IC, yes, globally deleted messages do indeed get removed from connected clients almost immediately.

While I might not like a message to disappear while in the process of reading it,
this may on the other hand be a way to quickly correct a typo in the chat... :)

_

However, this change will have a side effect which you are not expecting: the chat client treats messages with no user name as system-level notifications, so any messages you post as "nobody" will be listed in the client with the name "notification".

There is also another implication:
the posting clients time is called "server time".
F.e. like so:

2021-04-07 19:40:19 guest time 2021-04-07 05:40:19 zulu 2021-04-06 19:40:19 server time

The "guest time" line will be different for other clients - it is the time of the client reading the time info
and the above is how it looks for the "nobody" client.
But the other lines should be the same for all clients.

2021-04-07 19:40:19 guest time
2021-04-07 05:40:19 zulu
2021-04-06 19:40:19 server time

The "guest time" line will be different for other clients - it is the time of the client reading the time info

Correct. If the same user (or non-user, in the case of a guest) is using chat from multiple time zones, each will see its own browser-local time there.

and the above is how it looks for the "nobody" client.

The name "server" is what the chat client uses when no user name is associated with the message:

https://fossil-scm.org/home/file?ci=a044fea7850b8372&name=src%2Fchat.js&ln=704

The lack of a name is how chat.js internally distinguishes server-generated messages from client-generated messages. The reason guest's messages have no user name is because fossil internally uses a user name of NULL to mean "no user is logged in" (i.e. the "guest user is logged in"), and we really, truly never intended that such a user should ever get access to chat. That difference is now resolved in the trunk for new messages posted by a guest user, but will still affect (cosmetically only) any older messages submitted by a guest user unless you update the chat table:

update chat set xfrom='nobody' where xfrom IS NULL AND mdel IS NULL;

The name 'nobody' was chosen over 'guest' because that's the string fossil uses internally for that particular special-purpose name.

The name 'nobody' was chosen over 'guest' because that's the string fossil uses internally for that particular special-purpose name.

It seems like the most consistent and sensible choice to me as well.

"nobody" is already a reserved user name, basically for that same purpose - the non logged in user, while "guest" can be used as a normal user login.

If "nobody" ever posts in the chat, that should now be as obvious as with any other user.

With a non empty xfrom, the chat will display a rather normal message, including the message id, that was not displayed for those "notification"s.

The one thing that is different for the user "nobody" is that they can not delete their own messages.
(I'm only judging from the fact, that there is no "Delete globally" button displayed for them.)
The user "anonymous" can delete their own messages - even if they might be a different "anonymous".

None of them should probably be normally allowed into the chat, but I still like the option to do so.
It may be nice or useful for special circumstances or purposes.

The one thing that is different for the user "nobody" is that they can not delete their own messages. (I'm only judging from the fact, that there is no "Delete globally" button displayed for them.)

That's actually a bug (caused by the user having no name, which we need for the client-side "can they delete stuff" check (the server validates that before permitting deletion, of course)), but arguably a good one: if that worked for the nobody user, anyone visiting the chatroom could delete any messages posted by any nobody.

To stress again: we never intended /chat to be usable by non-developers. Thus i am extremely hesitant to add code which improves the experience for "nobody". The segfault fix was necessary, but features which elevate nobody to a full-fledged chat member are arguably not.

None of them should probably be normally allowed into the chat, but I still like the option to do so. It may be nice or useful for special circumstances or purposes.

Never, ever do it on a public repository. That way lies spam bots. It's only a matter of time before someone scripts spambots which check for public /chat rooms. Such bots already exists for spamming fossil wikis and tickets.

That's actually a bug (caused by the user having no name, which we need for the client-side "can they delete stuff" check (the server validates that before permitting deletion, of course)), but arguably a good one: ...

I was having similar thoughts.

_

To stress again: we never intended /chat to be usable by non-developers. Thus i am extremely hesitant to add code which improves the experience for "nobody".

That is quite understandable.

_

Never, ever do it on a public repository. That way lies spam bots. It's only a matter of time before someone scripts spambots which check for public /chat rooms. Such bots already exists for spamming fossil wikis and tickets.

Yes, the war of the bots seems to be on for quite a while...

And the restrictions required to keep bad/evil bots at bay make it harder for good/non evil bots to do anything useful at all.

And the restrictions required to keep bad/evil bots at bay make it harder for good/non evil bots to do anything useful at all.

Well you can always create a user for the bot and have it log in. Just assign the bot use only the chat ability and you should be all set. Or am I missing something?

-- rouilj

I was talking in general, not addressing one specific problem.
I was not really thinking about fossil in that context.

There is some frustration f.e. about some sites that used to be quick and easy to use...
but now require time consuming captchas, that I myself sometimes even struggle to solve...
forget about automating anything with them.
Some sites found it necessary to impose much narrower limitations for their use,
that even reduced their usefulness for purely manual users...

But I guess we should not discuss such things here any further.