| 28 May 2021 |
|  m4dr3r4 joined the room. | 07:12:30 |
|  James Salter joined the room. | 07:33:09 |
| James Salter left the room. | 07:37:30 |
| James Salter joined the room. | 07:37:51 |
|  jcgruenhage joined the room. | 07:43:44 |
|  michal joined the room. | 07:43:46 |
|  unknown joined the room. | 08:26:29 |
|  mrckndt joined the room. | 09:40:59 |
|  Henri Carnot joined the room. | 09:45:09 |
|  _slack_filecoinproject_U0225CQQZKK joined the room. | 09:51:36 |
|  madacol joined the room. | 10:04:18 |
|  5u joined the room. | 10:07:52 |
|  ˈt͡sɛːzaɐ̯ joined the room. | 11:26:31 |
|  cvantum joined the room. | 12:05:08 |
|  gggg joined the room. | 13:23:55 |
| gggg | hi folks...
i was wondering if pinata supports filecoin yet | 13:24:51 |
|  fy00zh3n joined the room. | 13:31:56 |
 carado | hmmmmm, i'm not sure if i'm a fan of IPFS objects being based on protobuf
i'm designing a format in which modules can have IPFS multihashes pointing to other modules, and i'm tempted to design that format on top of IPFS objects (with dependencies as the array of links and the rest of a module's information as the data), but i want my format to be relatively simple to parse and i'm not sure implementing a subset of protobuf that parses just IPFS objects is that easy | 14:16:17 |
| carado | * hmmmmm, i'm not sure if i'm a fan of IPFS objects being based on protobuf
i'm designing a format in which modules can have IPFS multihashes pointing to other modules, and i'm tempted to design that format on top of IPFS objects (with dependencies as the array of links (all with empty names) and the rest of a module's information as the data), but i want my format to be relatively simple to parse and i'm not sure implementing a subset of protobuf that parses just IPFS objects is that easy | 14:16:29 |
|  matrix07012 joined the room. | 14:17:46 |
| carado | especially when IPFS could've just reused pretty good conventions it uses elsewhere, like unsigned varints: an IPFS object could just be
- an unsigned varint specifying the number of links
- each link as a its total size (as another unsigned varint) and then its multihash
- after those, the payload until EOF
| 14:25:16 |
| carado | (i personally don't like that names are involved and would rather such information be in the payload, but if there are to be names they can just be after the link as a varint for length and then the name as bytes) | 14:26:27 |
| carado | * (i personally don't like that names are involved and would rather such information be in the payload, but if there are to be names they can just be after each link as a varint for length and then the name as bytes) | 14:26:51 |
 FuseTim | IPFS use mainly IPLD objects/dag | 14:33:59 |
| FuseTim | By default, UnixFS relies on Protobuf for storing files in IPFS, but you can use other formats like JSON/DAG-JSON or CBOR/DAG-CBOR among others. | 14:35:11 |
| FuseTim | * By default, UnixFS relies on Protobuf for storing files in IPFS, but you can use other formats like JSON/DAG-JSON or CBOR/DAG-CBOR among others to create your blocks/DAGs. | 14:35:51 |
| carado | hmmmm | 14:36:56 |
| carado | looking into it i think my format would be more of an alternative to IPLD rather than defined on top of IPLD | 14:37:13 |
 willscott | carado: your description sounds like it would be representable within the IPLD schema. it would be an alternative to 'dag-pb' which is the name given to the protobuf representation used in IPFS, but you could make a codec so that ipfs or other ipld libraries could traverse through your format in the same way they do through protobuf objects | 14:45:10 |
| carado | oh, that's good then | 14:45:35 |
