# Last week updates

- Bring own bucket with raw files at rest and detached UnixFS indexes
- Building blocks
- https://github.com/vasco-santos/hash-stream/tree/main/packages/utils#indexunixfs
- https://github.com/vasco-santos/hash-stream/tree/main/packages/index-pipeline
- Usage Guide
- https://vasco-santos.github.io/hash-stream/guides/bring-own-storage/
- Cloud PoC Available
- https://github.com/vasco-santos/hash-stream-index-pipeline-cloud-poc
- Location Hinted URIs
- Library
- https://github.com/vasco-santos?tab=repositories
- Use cases definition for Location Hinted URIs
- https://hackmd.io/gJj-IjtSTROMQFOJNPyG6w#
- Stalled PRs to add support in Helia verified fetch
- https://github.com/ipfs/helia-verified-fetch/pull/242
- https://github.com/multiformats/multicodec/pull/380
- https://github.com/ipfs/specs/pull/504
- Protocol Berg presentation slides almost ready
- https://docs.google.com/presentation/d/1XVuVF2X1Gmi4d-LR7hUBA6isyVJ_cElaBgImVfeelYY/edit?usp=sharing
- Note: We need to deliver slides beforehand and need to use their setup. So no live demo

# Open discussion points

## Release Helia fork

### Context

Helia PRs never got more engagement from Alex and he never got back to me when messaged him that PRs were ready for him to review, since the IPIP drama

### AI

TBC
- Release fork `@vasco-santos/verified-fetch` we can show working code snippet work with query param + HashStream Server

## Namings position

### `lochint` vs `provider`

#### Context

We renamed from `lochint` to `provider` based on Shipyard team. But `provider` name is also getting backlash at the same time in the IPIP.

#### Decisions

**Direction**
- [x] Keep as is until we have more knowledge
- [ ] Rename for what we feel is better name

**AIs/Comms**
- [ ] Talk to Shipyard team/lidel in HashBerg that we would like to rename to hint like: `provhint` or `lochint`

### Spec/library name

#### Context

Based on current query name, spec and library are now called `provider-hinted-uri`.

#### Decisions

**Direction**
- [x] Keep as is until we have more knowledge
- [ ] Rename for what we feel is better name

### Protocol component in multiaddr

#### Context

We started with `multiaddr:proto` encoding, and moved forward with `dns/hashstream-server.com/tcp/443/https/retrieval/tgwV1`, based on Alex recommendation to use `multiaddr` tuples with `retrieval`. There is also controversy in the [multicoded PR](https://github.com/multiformats/multicodec/pull/380) about `retrieval`. Folks seem onboard with `tag` given it is not limited to retrieval, that is can be re-used in several contexts and parser can see which TAGs are of interest.

Riba also suggested `type` yesterday aligning with `content-type`. But just `type` within multiaddr context is also not great git.

#### Decisions

**We want to get rid of `retrieval` anyway!**

**Direction**
- [x] Transition to `tag`
- [ ] Decide on our naming convention

**AIs/Comms**
- [ ] Update PRs (multicodec, provider hinted uri) + IPIP to use tag

ipfs://bafy....?provhint=dns/hashstream-server.com/tcp/443/https/tag/tgwV1

### Protocol Code table names

#### Context

We need code agreements so that clients can see what to do when they find them in a `multiaddr`. Shipyard feedback so far would be that they would like same dictionary as libp2p (e.g. `/ipfs/bitswap/1.2.0`), and there is already a different dictionary in usage in IPNI ("transport-bitswap" and "transport-ipfs-gateway-http"). Moreover, we should track versions.

Current table:

| Protocol Code | Description |
| ------------- | ------------------------------------------------- |
| tgw-v1 | Trustless IPFS Gateway v1 (raw blocks and CAR) |
| tgw-v1-raw | Trustless IPFS Gateway v1 for serving raw blocks |
| tgw-v1-car | Trustless IPFS Gateway v1 for serving CAR files |
| octets | Static server serving bytes hashed with sha256 |
| rasl | Content-addressed resources hosted in RASL server |
| bitswap-v1.2.0 | IPFS Bitswap protocol |

#### AI

Decision:
- [x] Get names flushed out

## Comparison Table reframing

### Content

Table could be controversial and not be seen as friendly from other teams, which has been preventing us from comparing it. Now is in better shape https://hackmd.io/RVIP2pSYTJCmaacUK_QX4g

### AI

Decision:
- [x] Can we share it with Bumble Fudge and Robin?

## Org for Hash Stream

### Context

We kept all the repositories in Vasco's account, while deciding where this should live.

### AI

Decision:
- [ ] Create Hashstream org before Protocol Berg and move everything there?
- [x] keep it for now as is

## Index stored backed by Postgres Store (Singularity Schema)

### Context

We want to make it simple for IA to try out HashStream. But we prioritized last week other streams.

### AI

Decision:
- [ ] @vasco-santos can start working on it

# Next steps

## WIP/Next

1. @vasco-santos to wrap up Protocol Berg presentation
2. @vasco-santos to prepare for Hashberg links discussion
3. @vasco-santos to write Index Store backed by Singularity Postgres DB
4. @vasco-santos to wrap up Protocol Berg presentation
5. Follow up with IA
6. (we decided in the 29th of April to not reach out yet) Reach out to ChainSafe

---
---
---
---
---
---

## Ideas / potential follow ups

1. Client Scoping
2. Lite client - what if we only use CARs and UnixFS for first iteration? this could potentially unblock old large players like IA, while is an initial step towards a fully implemented smart client, as well as be helpful for server adoption
3. PoC Deployment using Blake3/commp to clearly prove functionality out of typical IPFS direction

## Notes on other potential adopters

1. Chainsafe - they could run a dumb server for dumb clients over the entire filecoin tree - blobs are good - IA first, then we will see
a. STATE - not reach out for now

# Adoption paths / Key differentiators

- **Can server trustless content addressable data**:
- no matter how it is hashed
- no matter if it is content addressable at rest, or in a raw format

                         +-------------------------+
                         |  📦 Content Provider    |
                         |  (has some stored data) |
                         +-----------+-------------+
                                     |
                    +-------------------------------+
                    |                               |
     +--------------v-----------+     +-------------v--------------+
     |  Is the data raw format? |     | Is the data content-       |
     |  (e.g. regular files,    |     | addressable at rest?       |
     |   S3 buckets, etc)       |     | (e.g. CAR files, blocks)   |
     +--------------+-----------+     +-------------+--------------+
                    |                               |
        +-----------v-----------+        +----------v-----------+
        | Create content index  |        | Create content index |
        | (e.g. DAG with byte   |        | pointing to content- |
        |  ranges over files)   |        | addressable data     |
        +-----------+-----------+        +----------+-----------+
                    |                               |
        +-----------v-----------+        +----------v-----------+
        | Serve via Hashstream  |        | Serve via Hashstream |
        | with BYO Storage      |        | as-is                |
        | - No re-upload        |        | - No re-upload       |
        | - Any hash: UnixFS,   |        | - Any hash: UnixFs,  |
        |   Blake3, custom...   |        |   Blake3, custom...  |
        +-----------------------+        +----------------------+

                          => 🟢 Trustless delivery of content
                          => 🔄 Works across IPFS / non-IPFS
                          => 🔧 Supports flexible hashing
                          => ☁️ Bring Your Own Storage (BYO)