Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by darrenf on Friday June 14, 2019 @06:50AM
(#20181927)
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)
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by darrenf on Friday June 14, 2019 @08:43AM
(#20182493)
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.
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by seandougall on Friday June 14, 2019 @10:52AM
(#20183480)
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).
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by np_tedious on Friday June 14, 2019 @07:41AM
(#20182138)
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
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by prashnts on Friday June 14, 2019 @06:37AM
(#20181879)
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 [email protected]. 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.
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by albertgoeswoof on Friday June 14, 2019 @06:47AM
(#20181914)
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)
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 [email protected] is the recipient, it will be the sender to any replies, rather than the MUA default replying with [email protected] (but that's a separate discussion)
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by prashnts on Friday June 14, 2019 @07:55AM
(#20182212)
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.
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by mgliwka on Friday June 14, 2019 @05:55AM
(#20181714)
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 "[email protected] Text" get's parsed as [email protected])
Re:Show HN: Parse no-protocol URL, no-domain URI and email a...
by gray_-_wolf on Friday June 14, 2019 @07:24AM
(#20182068)
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).
To 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 [email protected] is the recipient, it will be the sender to any replies, rather than the MUA default replying with [email protected] (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#[email protected] 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.