This project attempts to parse url's and email addresses from text, even when the protocol is missing or they're mangled in some other fashion (i.e. google.com/test-url?id=2 gets parsed and identified as valid URL, but invalid.nontld/test not. Or "test@example.euSample Text" get's parsed as test@example.eu)
So it needs to be updated every time new tld is added? That seems... suboptimal. Also it will not work for intranet addresses (valid.insidemylan/test).
I think the "no-protocol" in the post message suggests the http(s) part is unnecessary. Makes sense - it's a pretty easy problem when the scheme is there
I’m just wondering if it can parse things like « pls-no-spam at google’s email service », which a human can easily parse to pls-no-spam@gmail.com. I suppose POS tagging with some heuristics can get it working for a few cases.
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.
Not sure why people bother to use the << spam at google's email >> approach when they can use an email forwarding service that lets you turn email addresses off, like https://idbloc.co (disclaimer, I built this)
Fastmail lets you convert myusername@fastmail.com to whateverwebsiteorservice@myusername.fastmail.com
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)
That example is quite common within academic context: most of the researchers and professors I know, who have a university homepage, use this.
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.
To the OP: I would suggest normalising the protocol. Your examples show that you retain the case from the raw data:
"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)
Interesting, thanks. I have virtually zero JS experience so didn't know that, and were I to try and pick it up this would've been a surprise to me - I naively assumed it would use the same terminology as the RFC and the libraries in languages with which I am familiar (rust, golang, python, perl). A quick look for the URI data type in a handful of other languages shows they also use "scheme". JS appears to be the outlier here.
In particular, the scheme doesn't necessarily refer to a protocol (e.g. application-specific schemes like `chrome:` that don't involve network access at all).
31 comments
[ 3.0 ms ] story [ 63.4 ms ] threadThat would be even more clear.
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.
(More likely to be useful than Outlook's typically wildly incorrect guesses at when someone's suggesting a meeting/calendar event!)
I use anti spam addresses to register to new services.
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.
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.
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)
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.
To that end, you might also want to consider adding support for fragments. :)
eventually it will get integrated with: https://github.com/jakeogh/kcl/blob/master/kcl/htmlops.py