1. Do you guys consider you have exhausted your ~1 full-time month of development? (You may have decided to stretch it on a longer period)
keks: Intuitiveley I'd say we did more hours, but that's hard to say because I didn't track my time. We are working on this part-time since the grant was accepted, ie. about half a year. While at first I could concentrate on this project fairly well, I later had other obligations which led to me switching context a lot, which has somewhat hindered my productivity every now and then.
cryptix: Keks did a lot of work in advance (implemented luigi and margaret on it's own) before I had the chance to collaborate because I was still tied up in other projects. In the beginning, each of us working on their parts was okay. Towards the end it would have been better if we had more time together to figure out needed changes to the design we started with. In total, yes. I used more time than I allocated in advance. I planned to spent more time on it afterwads in any case but setting clearer boundaries might have reduced unfinished stress.
2. What are the things you have achieved that others can build upon now?
We believe what others can build upon the most is
- An working foundation you can extend upon to support more commands. Namely the ability to define muxrpc handlers for the different parts of the system.
- working message verification
- the new muxrpc interface with luigi streams should allow client development in Go.
- another implementation can be a helpful reference for future implementation efforts
3. What part(s) of the initial proposal still need to be completed? (No need to feel shame if not everything was done, this is a learning process not an exam...)
For a while now we have all the individual parts done, but we still need to tie them together in a maintainable way. This is a bigger task than we anticipated, and we've been stuck doing that for roughly two months now. We're still working on that, though :)
There are a lot of small things that need to be done which we set out do but were pushed back because the integration of the big parts didn't go as smoothly as we naivly thought. Firstly, we need to be able to craft/publish (format, sign and replicate) our own messages in pure Go. Also, blobs support is still not implemented, but that is a low-hanging fruit as well.
The testing setup on the other hand is a wild mess of hotglue and could use a cleaner setup. Right now I (cryptix) craft a couple of messages in a nodejs instance, manually by hand. Sync them by running gossip.connect
and then check in the new go-ssb repo (repo is our name for the .ssb folder with the database) as testdata for our unit tests. Now that we moved to multilog, I need to redo this but don't want to redo this every time we change something. Personally I prefer to start with message crafting as that would scratch other itches as well but feel like it opens another can of worms.
Another thing we had in our proposal was the development of a plugin system. Unfortunately, this won't make it in the final release, at least not in it's full and more interesting form. However, we started a community process to design a sane plugin system that solves everyone's needs. This seems like the better path to us, because there are many people who wrote much more ssb code than us, and it would be ignorant not to rely on their experience.
To summarize, we are really not sure what the next best step is in our current state.