# DWN Refactor PR Notes

- [x] `requestId`
* I'd like to come up with 2 concrete use-cases / needs for `requestId` before including it.
* Consider this weirdness:
* >The object MUST include an `requestId` property, and its value MUST be the [RFC4122] UUID Version 4 string from the requestId property of the Request Object it is in response to.`
* But... what if someone sends a request without a `requestId`? Well.. we need to send a response back with a `status` indicating that the request is malformed. Reponse's **require** `requestId`s but no `requestId` was provided...
* :warning: **ACTION ITEM** https://github.com/decentralized-identity/decentralized-web-node/issues/165#issuecomment-1154365462

- [x] `messageId`
* `messageId` is the CID of the entire message. Does this include `data`?
- [x] `dateCreated`, `datePublished`
* ~~epoch seconds~~ or epoch ms?
- [ ] :warning: **CREATE ISSUE**:
* context: `DWN.processRequest`
* issue: how do we want to go about "validating" `Request#target`?
- [ ] Prep to have final WG discussion around UCAN vs. CACAO vs. CASA vs. our own JWS based stuff
- [ ] Talk about annoying shit with dag-pb unixfs stuff
- [ ] SDK DX

- in order to support `sharedAccess` we need to know the author of every message. How do we do that?
- add `author` to `descriptor` in every message
- **NO**. this leaks information about people
- make `attestation` **required** for every message
- **NO** because Daniel is a paranoid schizophrenic about the NSA.
- If DWNs are hosted by big cloud companies and individuals are buying drugs from one another, the Feds would be coming after those DWNs in a hurry
- make `authorization` **required** for every field with the signer being the application

const signaturePayload = {
    descriptorCid: 'asd098as09d8a9s08d90as8d',
    permissionsGrantCid?: 'asdkjsadlkjasdlkasjdd'
}

const msg = {
    descriptor: {},
    attestation: 'DURR_DURR_DANIEL',
    signature: 'JWS',
    authorization: PERM_GRANT_CID
}

| Method | auth required (y/n) | auth w/ capability required (y/n) | Notes |
| -------------------- | ------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `PermissionsRequest` | **Y** | **Y** | sig of grantee required |
| `PermissionsGrant` | **Y** | **Y** | sig of grantor required |
| `PermissionsRevoke` | **Y** | **N** | An invocation of a PermissionsGrant can be used to revoke the granted permission |
| `ThreadsCreate` | **Y** | **N** | |
| `ThreadsQuery` | **N** | **N** | |
| `ThreadsReply` | **Y** | ??? | |
| `ThreadsClose` | **Y** | ??? | |
| `ThreadsDelete` | ??? | ??? | I think that `ThreadsDelete` has very different implications depending on whether it's being sent to your own DWN or someone else's. |
| `CollectionsWrite` | **Y** | **Y** | |
| `CollectionsQuery` | **N** | **N** | |
| `CollectionsCommit` | **Y** | **Y** | |
| `CollectionsDelete` | **Y** | **Y** | |

## `published` Messages
- Published messages are messages that are accessible without capability invocation
- Published messages are never encrypted
- `CollectionsWrite` and `CollectionsCommit` are the only two messages that can be `published`
- sending a `CollectionsQuery` message with no capabilities invocation will return relevant `published` messages

const dwn = await DWN.create({ messageStore, didResolver });