add a number to websockets

[daviddias]

No description provided.

[daviddias]

@whyrusleeping I'm confused. go-ipfs uses ws for websockets but it seems that there is no reference for the ws on this package.

I want to make sure that we are using the same protocol name and number https://github.com/jbenet/js-multiaddr/blob/master/src/protocols.js#L44

[dignifiedquire]

Can we please use V instead of 0? As discussed before websocket addresses can have variable length, and this would make it much easier later on

[daviddias]

From what I heard from @whyrusleeping, @jbenet proposed that ws means 'no path' and wsn represents a websockets addr with paths.

[dignifiedquire]

Is this written down somewhere? Cause we should add these things to the multiaddr spec first before changing implementations all over the place

[daviddias]

💯 ％ agree.

[jbenet]

From what I heard from @whyrusleeping, @jbenet proposed that ws means 'no path' and wsn represents a websockets addr with paths.

wait, i thought it was:

• ws is path without a number telling you long the path should be (/ws/foo/bar/baz) -- cannot encapsulate
• wsn is a path with a number telling the number of path components (/ws/3/foo/bar/baz) -- can encapsulate

we could also do:

• ws16 a base16 (hex) encoded path or something /ws/2f666f6f2f6261722f62617a0a or ws32 or ws58 -- can encapsulate, variable length but not variable components

[jbenet]

And yes, +1 on getting this written down properly in multiaddr spec

[whyrusleeping]

having ws mean "path, but not encapsulated" makes it next to useless for us. Ipfs can't use a multiaddr that it cant encapsulate. The only distinction that makes sense is for ws to mean "No path" and wsn to be the number thing as we said.

[ghost]

Closing this as we've moved to using zero-length /ws (covered by #46), and will take care of HTTP paths sometime soon.