Show HN: Parse no-protocol URL, no-domain URI and email addresses etc from text
github.com
github.com
"protocol": "HTTP"
"protocol": "https"
As it stands, users will end up normalising by themselves and you can save them the effort. FWIW this part is typically called the scheme, not protocol (e.g. Perl has `URI::Find::Schemeless` which performs a similar task) URI = scheme:[//authority]path[?query][#fragment]
See https://tools.ietf.org/html/rfc3986#section-3To that end, you might also want to consider adding support for fragments. :)
But clearly HN likes it (it's number two...); can anyone explain it to me?
And if it can, I feel the most users for this would be email harvesting spam bots. Which would not be super nice. Although in ideal and less common scenarios it could actually be useful for IR purposes.
I typically use throw away email addresses instead since they're free. If I actually want to use the service/account some day I'll sign up properly.
I expect someday the primary email providers will generate aliases on demand.
It's not a literal alias, but it works out fine.
One of these days I'm going to propose the Thunderbird + K-9 mail addons that say 'set the sent from email address to be equal to the sent to email address', that way if service@myusername.fastmail.com is the recipient, it will be the sender to any replies, rather than the MUA default replying with myusername@fastmail.com (but that's a separate discussion)
The example above is about giving a direct line to be contacted through email on a personal site or blog, heck even a professional one.
> I expect someday the primary email providers will generate aliases on demand.
I know at least ProtonMail does it. But also theres the email#tag@gmail.com trick that works nicely enough.
I guess its because they do want legitimate people to reach them easily (students, collaborators etc) and if spams do go through — well they'd probably ignore it, just like they ignore other emails.
I use anti spam addresses to register to new services.
(More likely to be useful than Outlook's typically wildly incorrect guesses at when someone's suggesting a meeting/calendar event!)
eventually it will get integrated with: https://github.com/jakeogh/kcl/blob/master/kcl/htmlops.py
That would be even more clear.