Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a URL Schemes document as well #6

Open
DanielOaks opened this issue Apr 23, 2016 · 9 comments
Open

Add a URL Schemes document as well #6

DanielOaks opened this issue Apr 23, 2016 · 9 comments

Comments

@DanielOaks
Copy link
Member

DanielOaks commented Apr 23, 2016

This is an important part of IRC too. Take a look and see what specs (/IDs) exist for this and base ours off them, specifying what actual clients can do today.

Examples:

Current branch: url

DanielOaks added a commit that referenced this issue Apr 25, 2016
@DanielOaks
Copy link
Member Author

I think that commit should make things a bit nicer for when we do introduce that doc, maybe a little overkill for now but I think it's useful to do it now if we plan to host more than a single document

@DanielOaks
Copy link
Member Author

I really want to back this thing with some stats. Look at some various url datasets that have been published and see if any of them contain irc(s): urls (I presume they'd be filtered out of most due to the restrictions and # being an invalid character in urls proper as per the appropriate RFC.

There's also just getting one of those released datasets just containing a bunch of webpages, parsing those for the urls and using those as our dataset instead. I like this idea, but actually getting the money and the machine to be able to process those multi-terabyte files doesn't sound like too fun of an idea.

Maybe some of the groups that would actually handle irc urls on a regular basis could collect anonymised URLs on the actual structure of them (replace server names with a standard, replace names with #c and u if it's not in the explicit list of stuff defined in the Butcher draft), etc.

We could just go through and see what the clients support and implement some subset of that, but I think backing them with the data of what actual IRC URLs exist out there would be nice (if a probably unrealistic goal).

@DanielOaks
Copy link
Member Author

Backing them with actual data is going to be very, very difficult and require lots of groundwork... Just looking at what clients parse these days should be enough I guess.

@DanielOaks
Copy link
Member Author

Working on this over in the url branch

@DanielOaks
Copy link
Member Author

We need to figure out which exact parts of IRC URLs are followed these days.

This includes:

  • Username
  • Password
  • ischannel
  • isuser
  • isserver
  • isnetwork
  • key option
  • URI unencoding

@jwheare
Copy link
Contributor

jwheare commented Feb 5, 2017

Here's our implementation in IRCCloud. https://gist.github.com/jwheare/a1b5cae7f6adeb402bfcd1ec764b585a

Supports isuser otherwise assumed to be channel.

Also supports + notation on port to switch to ircs

@jwheare
Copy link
Contributor

jwheare commented Feb 5, 2017

We take URL encoded input from the browser and run url decoding before passing into this function.

User, pass and key aren't parsed out.

@jwheare
Copy link
Contributor

jwheare commented Feb 5, 2017

We also hard code a set of valid channel prefixes to test whether to prepend # rather than check isupport because the server may not be connected yet. Could improve this for connected servers though

I don't think the "try to join without prepending # then fallback if it fails" recommendation from the butcher spec is particularly reasonable.

@DanielOaks DanielOaks added the url label Nov 27, 2017
@TingPing
Copy link

Just for documentation: HexChat's uri support

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants