Is it possible to add URL shortening as a feature?

[Endo-Heikichi]

Is it possible to add a URL shortener that supports custom URLs.

Basically something similar to what's already been implemented in Rentry -

https://github.com/radude/rentry

[sven-hash]

Thanks for this proposition

Is it possible to explain me more ? Like you create a paste and you want to have the possibility to shorten the generated URL ? Or you want to have the possibility to shorten existing URL like bitly ? Or to be able to specify the URL id you want ?

[Endo-Heikichi]

1. My Idea:

What I had in mind is that when a user generates a paste, the URL generated by pastenym should be shorter.

The shortened URL ID itself can be random by default but the user can choose a specific phrase as the URL ID. The ability of customizing the URL ID will only be available when creating a paste and the custom URL ID cannot be edited once it's created.

This is an example of how it has been implemented in Rentry -

• https://rentry.co/NymMixnet
• https://rentry.co/zswze

"NymMixnet" is the custom URL ID. While "zswze" is the randomly generated URL ID for a scenario where no custom phrase is entered.

2. Not part of my idea:

• I don't think we need to add the ability to shorten existing URLs, that feature doesn't suit a pastebin service imo.
• We also shouldn't allow the custom URL IDs to be editable once they are generated.

[amadeous]

Thank you for your input.

If I understood your request properly, you would like the ability to define custom URL ID. Moreover, you state that generated URLs should be smaller?

Regarding the customization of URLs, we could think about it. It might however come with some additional concerns regarding privacy.

Now about the size of the URLs, you might have noticed that the URLs have the following structure: https://<domain.tld>/#/<urlID>?key=<some_key>. I will detail each element here and the rationale for the current size and influence we could have over it:

• <domain.tld>: this depends on the chosen domain name. We could have chosen a shorter domain name. As we wanted to showcase our software, we chose a corresponding name. However, should you need short Pastenym URLs, you could (and some have) setup your instance using a short <domain.tld>.
• /#/: is required as part of HashRouter. As you may now, what follows a # in a URL is not (usually) sent by browser to the web server, allowing to not reveal the paste (and key) you are querying to ISPs or intermediate network providers.
• <urlID>: this part is a few characters long (except when storing on IPFS). We aim at having non-sequential urlID to prevent enumeration and making it harder to retrieve someone else's paste without the urlID. For this reason, the size of the urlID should be large enough to be able to generate enough paste without running out of IDs for a long time. If we were running out of urlIDs (because all of them are used already), we would need to increase this size, that could give information that most of the IDs with the initial size are used (so enumeration would be successful with high probability). The current size has been defined without much thought but could be improved. If you choose to store your paste on IPFS, the urlID is the cid provided by IPFS so that the paste can be retrieved from any instance (or independently). Its size is fixed.
• <some_key>: this query parameter is used to derive the key used for the client-side encryption, as part of a key derivation function (more information about the library we use here). I am not a cryptography expert but my guess is: the longer the key, the more entropy is available to the key derivation function, the better the security provided. The current value is twice the one chosen for the demo of the library (here), it should be good, maybe overkill.

As you can see, beside choosing a shorted domain, there's not that much we could do. We will think about the size of the urlID but probably to increase its length, now that we have a bit more data about the usage. Please feel free to disagree and make your point, I might be wrong.

I hope this brings some insights about the way things were thought.

[amadeous]

Thank you for your input.

If I understood your request properly, you would like the ability to define custom URL ID. Moreover, you state that generated URLs should be smaller?

Regarding the customization of URLs, we could think about it. It might however come with some additional concerns regarding privacy.

Now about the size of the URLs, you might have noticed that the URLs have the following structure: https://<domain.tld>/#/<urlID>?key=<some_key>. I will detail each element here and the rationale for the current size and influence we could have over it:

• <domain.tld>: this depends on the chosen domain name. We could have chosen a shorter domain name. As we wanted to showcase our software, we chose a corresponding name. However, should you need short Pastenym URLs, you could (and some have) setup your instance using a short <domain.tld>.
• /#/: is required as part of HashRouter. As you may now, what follows a # in a URL is not (usually) sent by browser to the web server, allowing to not reveal the paste (and key) you are querying to ISPs or intermediate network providers.
• <urlID>: this part is a few characters long (except when storing on IPFS). We aim at having non-sequential urlID to prevent enumeration and making it harder to retrieve someone else's paste without the urlID. For this reason, the size of the urlID should be large enough to be able to generate enough paste without running out of IDs for a long time. If we were running out of urlIDs (because all of them are used already), we would need to increase this size, that could give information that most of the IDs with the initial size are used (so enumeration would be successful with high probability). The current size has been defined without much thought but could be improved. If you choose to store your paste on IPFS, the urlID is the cid provided by IPFS so that the paste can be retrieved from any instance (or independently). Its size is fixed.
• <some_key>: this query parameter is used to derive the key used for the client-side encryption, as part of a key derivation function (more information about the library we use here). I am not a cryptography expert but my guess is: the longer the key, the more entropy is available to the key derivation function, the better the security provided. The current value is twice the one chosen for the demo of the library (here), it should be good, maybe overkill.

As you can see, beside choosing a shorted domain, there's not that much we could do. We will think about the size of the urlID but probably to increase its length, now that we have a bit more data about the usage. Please feel free to disagree and make your point, I might be wrong.

I hope this brings some insights about the way things were thought.

[Endo-Heikichi]

Thanks for the detailed explanation. This does put things into perspective.

[Endo-Heikichi]

Thanks for the detailed explanation. This does put things into perspective.