00:09:07  <mafintosh>noffle: i'm not sure i completely understand the huge benefit of using the same binary format tbh.
00:09:27  <mafintosh>noffle: since protocols will differ anyway. maybe i'm missing something though
00:10:06  <mafintosh>noffle: using the same high level format might make interoperability easier between modules
00:15:20  <noffle>mafintosh: when I say binary format I'm referring to the data that makes up the final hash. if we can't agree on this then any interop is impossible, since our hashes won't agree
00:15:43  <mafintosh>noffle: ah sry i thought you meant something else
00:15:49  <noffle>maybe wire format? my err
00:15:56  <mafintosh>noffle: sure i can see the value in that
00:16:41  <noffle>yeah; even with differing protocols, being able to exchange compatible structures that form merkle dags with merkle links would be huge
00:17:10  <noffle>suddenly ipfs can link to hyperlog and dat and ssb and whatever else; even if we all have different ideas about what happens on the stack from there upwards
00:18:01  <noffle>it seems like only partially a technical problem. I suspect dat and ssb will eventually realize that structured data /w merkle links is the way to go, but it's a political problems re choosing that format and whether you want to care about compatibility
00:18:36  <noffle>I'm pro efforts like multiaddresses and multihashes that try to define a standard format that can grow and encourages interop
00:22:27  <mafintosh>noffle: i just don't like bike shedding abstract things in groups hehe
00:24:02  <mafintosh>noffle: only thing that worries about standardisation of everything is initial mental overhead for newcombers
00:24:27  <mafintosh>noffle: understanding a protocol becomes a lot more tricky if you have to understand 10 different abstract things first
00:25:41  <noffle>mafintosh: that makes sense. ipfs prefers to put a lot more One True Way and mental model overhead onto users than the small hyper* modules and friends
00:27:17  <mafintosh>noffle: i think there is a good middle way
00:27:27  <mafintosh>noffle: like in hyperlog where you added the 'hash' option
00:27:39  <substack>it seems like you can make a merkle dag using any hash if there is enough metadata in the hash string
00:27:58  <mafintosh>noffle: that makes it easy to use a multihash if you want to but you don't have to understand multihash to understand hyperlog
00:28:04  <noffle>right
00:28:25  <substack>I'm not seeing how it matters very much which hashes are in play, just something clients may or may not need to worry about
00:29:18  <noffle>substack: ah you're considering much purer layers than I think ipfs is
00:29:23  <substack>you can always embed links into data, the merkle structure is implicit in the causality of hashing algorithms
00:29:36  <substack>like <a href=""> links or json or whatever format you want
00:30:02  <substack>and the properties of the dag will still hold
00:30:08  <noffle>hyperlinks do have a common scheme though, and there's value to that
00:30:50  <noffle>the web does interop well
00:39:35  <noffle>substack: I think at the hyperlog level it doesn't matter which hashes are at play (since you can plug them in and they have no semantic meaning other than verification & causality)
00:41:04  <noffle>substack: I'm thinking more on applications (like swarmbot-*) that start to put retrieval semantics into the hash (resolving a magnet link hash inside a hyperlog is different than resolving a link to e.g. another hyperlog or an /ipfs/ multiaddr)
00:42:01  <noffle>you adding a 'link' property that means "this is a link to a magnet link" implies a need for structured data that links to other merkle dags
00:42:56  <noffle>I suspect this will come up more and more as people start to develop applications on top of hyper*/ipfs/ssb/etc and want to embed data structures in merkle nodes that are aware of merkle links as well
00:43:25  <noffle>so having things like e.g. path resolution of merkle links (/hyperlog/somesha1/author/name) will be important
00:53:33  <substack>noffle: I don't think so. I could just as easily add a link that isn't a magnet
00:53:38  <substack>an http link or an ipfs link
00:53:44  <substack>or use an array instead of a string
01:05:13  * phatedjoined
01:09:59  * phatedquit (Ping timeout: 240 seconds)
02:10:10  * contrahaxquit (Quit: Sleeping)
02:11:25  * contrahaxjoined
02:12:23  * contrahaxquit (Client Quit)
02:27:34  * vweeversquit (Ping timeout: 244 seconds)
02:53:34  * phatedjoined
02:58:11  * phatedquit (Ping timeout: 248 seconds)
03:27:46  * dguttmanquit (Quit: dguttman)
03:34:56  * Kralnjoined
03:50:52  * phatedjoined
03:55:27  * phatedquit (Ping timeout: 250 seconds)
04:47:52  <noffle>I'll think about this some more
05:34:28  * dguttmanjoined
05:36:07  * brodavijoined
05:40:57  <brodavi>so I've got a swarmlog of browsers running, and I want to share a file using webtorrent. is it unreasonable for me to think that the signalhub should act as a tracker, in lieu of a webrtc dht? I have tried simply plugging in the simple-peers from the swarmlog swarm into the torrent-swarm, but I ran into some issues
05:45:04  * domanicjoined
05:47:32  * phatedjoined
05:48:53  <substack>brodavi: I don't think it's possible to specify a custom swarm with webtorrent right now
05:49:14  <substack>webtorrent has its own way of swarming separate from the swarmlog
05:50:32  * dguttmanquit (Quit: dguttman)
05:52:15  <brodavi>okay thanks, that definitely helps. rabbit-hole avoided
06:22:41  * roeychanged nick to Boobileah
07:02:11  * fotoveritequit (Quit: fotoverite)
07:15:59  * domanicquit (Ping timeout: 240 seconds)
07:29:58  * domanicjoined
07:46:34  * phatedquit (Remote host closed the connection)
08:23:21  * domanicquit (Ping timeout: 276 seconds)
08:31:11  * domanicjoined
08:31:22  * contrahaxjoined
08:41:45  * phatedjoined
08:46:27  * phatedquit (Ping timeout: 248 seconds)
09:31:36  * domanicquit (Ping timeout: 276 seconds)
09:33:01  * vweeversjoined
10:06:00  * djcoinjoined
10:09:54  * brodaviquit (Quit: Page closed)
10:28:42  * contrahaxquit (Quit: Sleeping)
10:29:52  * phatedjoined
10:31:47  * contrahaxjoined
10:33:13  * nathan7quit (Changing host)
10:33:13  * nathan7joined
10:34:19  * phatedquit (Ping timeout: 255 seconds)
10:41:28  * brodavijoined
11:03:41  * djcoinquit (Quit: WeeChat 1.0.1)
11:36:49  * contrahaxquit (Quit: Sleeping)
11:47:12  * phatedjoined
11:52:00  * phatedquit (Ping timeout: 276 seconds)
12:53:43  * vweeversquit (Ping timeout: 252 seconds)
12:54:26  * vweeversjoined
14:12:28  * djcoinjoined
14:28:18  * pfrazejoined
15:04:28  * PsionTheoryjoined
15:09:49  * fotoveritejoined
15:11:28  * coderzachjoined
15:25:12  * dguttmanjoined
15:26:08  * PsionTheoryquit (Read error: Connection reset by peer)
15:27:52  * coderzachquit (Remote host closed the connection)
15:39:24  * Tristit1ajoined
15:39:59  * Tristitiaquit (Ping timeout: 240 seconds)
15:47:31  * Tristit1aquit (Excess Flood)
15:50:52  * Tristitiajoined
16:10:06  * brodaviquit (Quit: Page closed)
16:12:58  * coderzachjoined
16:15:45  * pfallenopquit (Quit: leaving)
16:17:02  * pfallenopjoined
16:41:58  * mk30quit (Ping timeout: 255 seconds)
16:43:10  * mk30joined
17:22:20  * djcoinquit (Quit: WeeChat 1.0.1)
18:09:05  * coderzachquit (Remote host closed the connection)
18:15:09  * coderzachjoined
18:36:46  * phatedjoined
18:52:58  * rwaldronjoined
18:57:43  * coderzachquit
20:30:08  * domanicjoined
20:56:35  * domanicquit (Ping timeout: 248 seconds)
21:34:01  * vweeversquit (Ping timeout: 244 seconds)
21:34:59  * vweeversjoined
23:17:45  * pfrazequit (Remote host closed the connection)