This is a summary of a discussion on IRC today: So OTRDATA right now requires an OFFER before anything can be retrieved using a GET. This makes sense to keep the security model simple.
But I thought of a use case where this is problematic: OTR public key syncing. The idea is that if you trust someone via OTR, you can also trust their verified state of OTR public keys. Right now, I'm mostly thinking about use cases to future proof the current implementation of OTRDATA in otr4j. Here's one idea I'm thinking of for this: there could be a GET that fetches an index at a known location. Then once the index is received, that side might want to get things it knows about from the index. One client might want to OFFER an index of their public key fingerprints using a unique URL, then the receiver would then choose to GET the keys it does not have. There coul be a recursive OFFER, so an OFFER is always required before GET, but you can send a recursive OFFER, and any sub-path could be GETed without more specific OFFER. For example: OFFER otr-public-keys:/kljasdflamsdioroaimoser/ GET otr-public-keys:/kljasdflamsdioroaimoser/ Now the client has the index, and can make a specific request: GET otr-public-keys:/kljasdflamsdioroaimoser/ba86e551ac56c1aeab Nathan proposed the recursive/subpath idea for getting different resulotion of images, or for other multi-part shares. But maybe that's more like a query string thing, like: OFFER otr-in-band:/path/to/image.jpg GET otr-in-band:/path/to/image.jpg?height=640&width=480 Images could then be stored locally at full res and OFFERed, then the receiver calcs a good size for their screen, then GETs using that size. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
