# The State of Transports and Links: HTTP & beyond

- you are here: https://ipfs.fyi/hashberg-notes
- schedule: https://ipfs.fyi/hashberg-schedule
- session-specific [TLDRaw board](https://www.tldraw.com/f/B2bqGfR3bxDOcLi06f1B3)
- Facilitator(s): Vasco Santos, Robin Berjon
- Scribe(s):
- In attendance (& quotable):
- Vasco
- Robin
- Cameron
- Daniel Norman
- willscott

## Context

- [Properties enabled by encoding hints in URIs](https://hackmd.io/@vasco-santos/ryCzUm4meg)
- [Provider Hints exploration](https://github.com/vasco-santos/provider-hinted-uri/blob/main/EXPLORATION.md)
- [RASL url provider hints](https://dasl.ing/rasl.html#the-web+rasl-url-scheme):
- note: these point to super-simple RASL `/.well-known/` endpoints, not to full ipfs gateways!
- [Content-addressed data over HTTP using magnet links](https://github.com/gordonbrander/magnetize)

## Notes (scribed)

- cameron: provider hints ween people off dht and edge-verification; shouldn't we push through to a better ipfs rather than abandoning the original architecture?
- will: is 'ipfs' a resilience fall-back, or does it have a positive pitch of being 'better' than http? if it's better - how?
- riba: have you talked to a user lately?
- field of dreams: build it and they will come?
- move away from artificial coupling of all the layers, people keep asking for 1 or 2 layers; ideal customer doesn't exist
- b5: aren't we already decoupling?
- riba: yes we're decoupling tech but we need to go back to use-cases, not to architecture
- vasco: if connection to DHT is required of all providers, it's a blocker to adoption...