https://0ut.ca/documentation
- Link Shortener, Tools, Parser/Validators, and API for +16 correct and complete RFC implementations for URI/IRI and Email components
I'm interested in continuing work with Golang, specifically on backend infrastructure. Web Services, Email, Storage, Security, and Distributed Systems are my main interests.
would 2 different torrents that contain a file with the same exact physical hash share the same torrent file hash?
if torrent A and B both contain the exact same file, but torrent A only has the first half available, and torrent B has the second half available, could I combine both torrents to download that file? this could help fix old dead torrents or at least make the file searchable elsewhere by it's sha256 for example
I have an implementation, although it's currently closed source and is only available via API: http://0ut.ca/documentation
I believe it's closest to the standard that I've found, and if it isn't I would like to correct that.
There is a Strict parser which will fail on any error, and Loose parser which will discard errors when possible and follow the defacto parsing implementations.
It should be able to handle any of the edge cases, such as partially percent encoded unicode, invalid characters, normalization, or octal/hex ipv4 addresses. The only thing from your linked unittests that it will not handle is | and \ for windows paths, they will be encoded.
- the spoofgo repo is the latest/largest public project I've released as an example of my coding style
I love working with Go and it would be great to continue working with the technology that I am familiar with. However, I am open to learning new languages. The ability to learn on the job is important to me. I'm interested in Distributed Systems, Ad Networks, Security Tools, and Crypto Currencies.
I've recently released a beta platform and API for tools for working with links: https://0ut.ca/
There's currently a Link Shortener, UTM Campaign Builder, Parser and Validators for 15+ RFC implementations for different URI components.
I have a lot of continuing work to do, such as better analytics, a user system, and more tools.
I haven't got any feedback yet, I would love to hear just about anything, it would be encouraging. Feedback about my implementations would be greatly appreciated. Thanks!
- the spoofgo repo is the latest/largest public project I've released as an example of my coding style
I've been programming since I was a child, I love it. I love working with Go and it would be great to continue working with the technology that I am familiar with. However, I am open to learning new languages. The ability to learn on the job is important to me. I'm interested in Distributed Systems, Ad Networks, Security Tools, and Crypto Currencies.
you could inform your users that email addresses are case sensitive much like passwords usually are or just normalize the local part along with the host and use that as the primary ID and have less issues in the future
servers that have case sensitive mailboxes are more likely to be used for throwaways or the user may control the server anyways so they could still respond to normalized local parts
as for verifying the email at registration you could check to see what the remote smtp server responds to when you issue the RCTP command to check if they consider the email valid
Hey, this is still in early beta. I've recently released an API for Validators of Email and different URI components. As for the shortener its self, there is no user system or analytics yet. Feedback is appreciated!
There's already a solution in the spec for the slash issue
Either you have a valid scheme or you don't, and either you have a relative path or an absolute path
Double slash after a valid scheme implies an authority, if a 3rd slash exists it's an absolute path, anything past the 3rd slash has to be normalized. So, http:////// is actually http:///
If you have an invalid scheme or a relative path such as http:/ or +http:// it would actually be normalized to ./http:/ ./+http:/
literals were introduced because the order of parsing for an email host is first "Domain" for any non literal, then literal which defaults to IPv4 [127.0.0.1], then a literal prefix was added for IPv6 and any future registered protocol "[IPv6:::]"
if you want to develop your own "standard" either use the literal IPvFuture, or use a Registered Name
non literals IPv4, IPv4Historic, and Domain names are valid registered names, but domain names aren't even part of the URI standard
the only reason you would have conflicts with domain names is because they're de facto parsed after an IP, so a double dot would probably be discarded as invalid, which is why punycode exists for unicode
if at that point you didn't have any conflicts it would be a registered name, but you wouldn't have any way to resolve them
lastly, if you want to fix the nonissue of double clicking use a registered name, if you chose to use underscore you may have conflicts with dns
Remote: Yes
Willing to relocate: Possibly (within Canada)
Technologies: Golang, RethinkDB, SMTP, PHP, MySQL, PostgreSQL, MongoDB, Elasticsearch, Memcached, Redis, Ubuntu, FreeBSD, ZFS
Résumé/CV: on request
Email: [email protected]
Recent Work:
https://0ut.ca/documentation - Link Shortener, Tools, Parser/Validators, and API for +16 correct and complete RFC implementations for URI/IRI and Email components
Github: https://github.com/sabey https://github.com/sabey/ishtargate - contextual template engine for iptables/firewalls
I'm interested in continuing work with Golang, specifically on backend infrastructure. Web Services, Email, Storage, Security, and Distributed Systems are my main interests.