Permalink URLs are too long for email usage

[stain]

Example of a very long URL:

https://lists.apache.org/thread.html/aadbecf2693e9add9ce9bdd2b98cc3d6e8c10c9db66a9934c5426ff8@%3Cdev.taverna.apache.org%3E

This kind of URL is too long to be pasted in an email (e.g. for an Apache VOTE process). As well this contain special characters like %3E

[Humbedooh]

Pony Mail supports short URLs for this very purpose. They are disabled on that specific installation due to the theoretical risk of duplicate short. Since you refer to lists.apache.org, I would suggest you merely use s.apache.org to shorten your URL :)

[sebbASF]

See also #41

[Humbedooh]

Reopening as we're working on a better URL shortener for the coffee-and-cake branch.
This will shorten the ID to something like 'PZ1ii9x4503us3eb04qvh3s'

[sebbASF]

Unless the shortener uses external information (such as a shortlinks database) it cannot be reversible unless the input URL has redundant information in it. In which case, it would surely be sensible to remove the redundant information from the URL? Or am I missing something here?

[WattsInABox]

At ApacheCon and working with Rich and Benjamin on some stuff at a Hackathon session on Barcamp day (sorry, Barcamp). We've been chatting about this issue and a couple things have come up:

1. s.apache.org requires authentication so it can't be used by everyone
2. the current long links aren't just long, they break some email clients
3. it should be easier to shorten URLs by getting back a short URL by default with the permalink button or by clicking something else to get the shortened permalink
4. Since Ponymail is going to be used by other people and companies (hopefully), shortening URLs should be an interface of some sort (we're thinking UrlShortenerService is a decent name) and should support a few implementations, GenericUrlShortenerService which could be configured for bit.ly or goo.gl or many others, and BasicAuthenticatedUrlShortenerService which could work for s.apache.org

Any objections to this plan? Speak quickly b/c I'm planning on implementing a first go at this like ... now. :)

[sebbASF]

2. Which e-mail clients are broken?

[sebbASF]

Note that Permalinks need to be permanent.
Whilst it seems unlikely that goo.gl or bit.ly will disappear, this should be borne in mind.

[WattsInABox]

Duly noted about permanency. We've also thought up built-in short links like https://lists.apache.org/s/some-link where some-link would be a 2-way hash of the current permalink. The /s/ page/controller/whatever would then decode the hash and redirect. Would that option be better for you? Either way, I'm going to program to an interface so we can, ideally, hotswap with a touch of configuration.

Someone else brought up the broken clients, I can look into it more.

[sebbASF]

As per my comment of Oct 2016, if it's possible to create a shorter 2-way hash of the existing variable part of a Permalink, why not use that as the Permalink in the first place?

Please note that the existing Permalinks are not guaranteed unique, nor are they guaranteed to remain the same if mails are reloaded.

Using a URL shortener does not affect this (as long as the shortener is guaranteed to always return the original URL).

[WattsInABox]

So in my estimation, the two-way encoding idea (it's not really hashing, I'm figuring out) doesn't really work because it doesn't actually shorten anything. Base64 encoding the current URLs or message IDs actually makes them longer.

If we do want shorter permalinks, and it sounds like we're headed that way, I think we would have to use the database. I was trying to stay away from a database-dependent solution, but I'm not sure how to avoid it at this point.

[sebbASF]

If it were possible, then URL shortening services would not need to exist as it could all be done in code...

However as mentioned previously, it may still be useful to have an optional add-on that automatically creates a short URL on demand using one of the existing 3rd party services.
(It would not make sense to create short links for every message)

I don't think the s.apache.org service is really suitable (even if authentication can be sorted out) because its URLs can be editted.

A strong and stable implementation would not be trivial and I think is out of scope for PonyMail.