# Development Update #5
It has been a couple weeks since my last update, and since then I have continued working on the content-key functions as well as implementation of OFFER/ACCEPT.

## Previous Goals
- Figure out SSZ sedes & sigp implementation crate to successfully design a scheme to decode all sorts of content-keys & open a PR for review
- Brainstorm & design how to rewrite the event handlers to create an event loop(s) to handle requests and responses. This includes studying how the current architecture in Trin works. Take a first stab at implementing this, if necessary.
- Finish the discv4 draft and write an outline for discv5.

## Progress
### Content Keys SSZ
I have renamed this from just working on the "derivation functions" to the larger issue of defining an SSZ encoding and decoding for the content-keys of the state and history networks. This is actually the main thing I've been working on, since before we can convert keys to ids, there must be explicit definitions of the keys first. The ids are just hashes, so the actual derivation functions are easy and just a byproduct.

So for the past weeks, I've gotten a fully working implementation of content-key definitions--they consist of a combination of enums and structs. Additionally, I wrote some encoding and decoding functions that convert a key to an SSZ encoded byte array, and decode a SSZ byte array to the appropriate key (struct). A lot of the implementation is analogous to the SSZ encode/decode for the message types in Trin.

The derivation functions came simply afterwards--they mostly consist of type conversions and then hashing the appropriate fields in the key as defined by the spec.

I also wrote a bunch of tests to make sure everything works. Basically, everything should be good to go, but I need to figure out how to deal with the overflow of U256s on one of the derivation functions.

### Architecture for handling responses & requests
There needs to be a lot of work done here. I took some time reading through the Trin codebase and I wrote a write-up and a picture detailing how it works and how all the separate components come together.

That was useful in helping to understand how everything should come together. I'm still a little confused on how to tackle this issue, but I consulted with a fellow member and got some ideas of how to approach this issue. I have taken a stab at designing an architecture, but there need to be many holes that need to be filled in and more thinking done.

For now, I will work on extending my stub implementations of OFFER/ACCEPT to now integrate it with uTP. This fits into the larger issue of handling responses in general (ie, for now I will work on how to handle ACCEPT responses) so that will be the next step.

### Devp2p Guidebook
There's a lot of work to be done on Trin right now, so I think will put the guidebook to rest for a bit. I will definitely pick it up in the future, perhaps after the cohort ends, but for now I've decided I want to devote my focus to helping implement and write code for Trin, as that is more of an immediate issue.

## Next Week's Goals (10/17/21)
1. Complete the Content Key SSZ - fix overflowing issue, use new types from `ssz_types` crate and make sure everything still works, clean up & organize code (make the functions methods, move `ContentKey` types to separate files)
2. Finish OFFER/ACCEPT implementation - integrate with utp and `PortalStorage`
3. Continue thinking, designing, tinkering with an architecture of how to handle responses in general