[Feature]: automatically link url-like stuff

[gerner]

Contact Details

nick.gerner@gmail.com

Enhancement Type

Message formatting

What is your idea or what can be improved?

Once messages have been received and are being rendered, it would be nice to automatically recognize url-like things and turn them into hyperlinks.

So if a message said "check out http://w7aw.groups.io" it would be rendered as <a href="http://w7aw.groups.io">http://w7aw.groups.io</a>

This is similar to how github is rendering this very issue body: it recognizes the url and turns it into a link at render time. I think this should only happen at render-time in the browswer client, not in the back-end stored data or anything like that.

There's gotta be fairly standard approach to doing this sort of thing since it's everywhere.

[ham-k7dev]

Done in my branch. ham-k7dev@91ed812

[hickey]

I took a quick look at your commit and it looks quite reasonable. Did you want to generate an MR?

[gerner]

Agreed, the change looks small and fairly low risk.

Tangent: I realize this change is client-side, which seems very reasonable. On the server do we ever sanitize the message, either inbound when first received or outbound when we send it to the web client? That might be something we want to consider for a separate work-item.

[hickey]

I would actually prefer not to make any modifications of messages on the server side (at least that is my initial thoughts on the matter) and leave it to the presentation layer (i.e. the front end code) to present the message in an acceptable format. My fear being that going down the road of altering the message on the server/in the database would later manifest itself as a difficult or impossible task to re-render the message with additional markup or present it in another format.

[gerner]

You argument seems reasonable. I agree we should keep it simple, not mess with the message body too much. Are you concerned at all that inadvertently or on purpose a message contains markup that messes with the presentation? It would be easy for the message to close the message container, add script elements, etc.

Perhaps we could sanitize the message in js, before highlighting links, sort of how \n is replaced with <br> by adding something along the lines of the first snippet from here: https://stackoverflow.com/a/2794366/553580 which just replaces < with < and similarly for other markup characters.

[hickey]

I say that but I can envision where a message is stored in the database but additional metadata is discovered by analyzing the message and it gets stored as part of the message entry. I don't have a full idea around this but I am thinking of something like it is observed that the message has a reference to a call sign and either pulls info from QRZ or stores a link to the QRZ profile.

I don't foresee anything really happening until a bunch more work is done on the database structure and the sync issues. I do sort of like the idea of making a plugin architecture that would allow for anyone to write a plugin to handle message parsing tasks. The plugin architecture would need to support both LUA and JS components to handle server and client side tasks. Just thoughts at this point.

[hickey]

I think the basic concern is that the more that the message is changed to suit one need it can make it difficult to repurpose the message for another need.

Just a bit hypothetical, but today the message is kept as plain text in the database. If the message was modified as it was stored (using your example of < changed to <) that might be fine for the existing WebUI presentation that is in place today but might add complications for someone that writes a bot to interact with messages.

I think keeping the "original" message is the best practice and then allow each application to decide how to react to the message. In my previous comment I extend that thought with eventually storing annotations with the original message that may provide hints to an application to enhance the presentation of the message.

[hickey]

Hmmm.... there maybe a spot or two in code where the message is modified before storage. There is just something in the back of my mind about that and I am going to have to go look at some code to determine if this really the case. I wonder if the message is modified because of the way it is being stored.

[ham-k7dev]

This version handles <br/> tags: https://github.com/ham-k7dev/meshchat/blob/links-into-links/www/messages.js#L263