maybe pull the changes into here?

[jbenet]

hey @diasdavid maybe pull the multistream changes into here?

This was a WIP i wrote way before the conversation we had on the train from Slovenia to Berlin. So it's outdated. Then-- i was considering switching the newline in favor of a / so that it didnt break things like ndjson.... but that may be a fraught endeavor. in any case, the last char is changeable, as it's included in the varint. maybe we could leave it up to the users to decide? (not sure). the niceness of the \n for streams is that it plays well with telnet.

[daviddias]

For sure, it would also be cool to break the msg-stream/length-prefixed stream into its own repo

ref:

• Call multicodecto multicodec :) multistream-select#3

[daviddias]

For ref:

IRC log
00:12 <+daviddias> jbenet: thinking through it again. why would \n in multicodec break ndjson? it should only become a ndjson stream after multicodec is interpreted 
00:13 <@jbenet> daviddias: oh, maybe that's fine. i guess depends how you use it. if you had a sequence of items, and each item was one entry (with its own header)
00:13 <@jbenet> i'm thinking of a stream that sends {protobuf, json, cbor} objects randomly, each object with a header.
00:13 <@jbenet> but yeah i guess all bets are off and newline is not really a big deal
00:14 <+daviddias> but that would mean that a thing like ndjson would have to speak multicodec or you always have a multicodec transform stream in front of the ndjson 
00:14 <@jbenet> my concern maybe is uses of multicodec in single-line situations
00:14 <@jbenet> true
00:16 <@jbenet> http://gateway.ipfs.io/ipfs/QmQWSYs4dCo9MNJMQiutRMSriyZiqM78fqBo8x1CHYwk1k/paste 
00:17 <@jbenet> meh
00:17 <+daviddias> ndjson is still passed as text
00:18 <+daviddias> if we have a ndjson thing in the midle
00:18 <+daviddias>   /ndjson/"{"hello":"world"}\n"
00:18 <+daviddias> the final (invisible) \n would be for multicodec 
00:18 <+daviddias> and the one inside quotes is for ndjson
00:19 <+daviddias> Maybe I'm missing something that you are seeing
00:20 <+daviddias> but I would say "put it on the boat!" 🚢 :)
00:20 <@jbenet> oh maybe. not sure, i dont know enough about how people might use this. like the base encoding ones, potentially, it's annoying to have a newline there? not sure.
00:20 <@jbenet> yeah sure.
00:21 <+daviddias> we can always put the decision on the developer, of using a new line or not (default to new line), if we come to find a protocol where it breaks things
00:22 <+daviddias> then the dev, just has to know that for that protocol, it also has to do the reading without the new line
00:23 <@jbenet> yep +1 to that idea

[vmx]

This is an issue about an older version of multicodec that does not apply to the current version.