Archive for October, 2019

Some stub thoughts on governance and risk management at a global level

October 25, 2019

There are various tremendously encouraging developments in many engineering areas at present, which I am quite tempted to share and discuss. However, rather than discuss these, it might be useful to make a few observations:

  • It is clear that at present, most practical engineering problems can be planned for and solved – even if they are difficult – over a matter of two or three decades, provided one makes a sustained and steady effort with a clear vision.
  • One should plan for and innovate in areas that are necessary sooner rather than later, in order to mitigate against certain risks (e.g. water security, ecosystem services, energy).
  • However, one should be cognizant of the dual use nature of much innovation and technology, and therefore understand problems inherent in a “progress trap” like fashion – new technologies might (and undoubtedly will) expose one to additional risks.
  • When technology becomes more advanced, the risks become larger, and therefore the need for better coordination and governance becomes even more essential.

So instead of discussing certain things, at least at present, I would like to talk about ways to mitigate against dual use technology risk. One key one here is the risk of different global players deploying technology in an adversarial way that might not be terribly constructive, and at the very least detract and/or distract from other problems that need to be solved.

The league of nations was supposed to be a prototype for this sort of thing. The present day incarnations of this concept are the EU assembly in Brussels, and the United Nations in the state of New York in the US. However there are problems with these. The main problem is that the UN sits within the physical bounds of a particular sovereign state, which means that its impartiality cannot be guaranteed.

A solution for this could be to have a virtual UN assembly, which met in virtual reality, with representatives that might be human, hive minds, artificial intelligences, and/or combinations of these.

Barriers to this sort of setup would be:

  • Low latency / instantaneous communication across the globe
  • Advances in haptic technology and virtual/augmented reality
  • High bandwidth connections
  • Advances in computing
  • Advances in artificial intelligence
  • Advances in cybernetics

In order to guarantee security of communication and protect against compromise, information transmission would need to be guaranteed by the highest possible forms of cryptography, maybe elliptic curve cryptography, or functions from the space of elliptic curves back to itself. Such security would protect against advances in computing.

This model of decentralised governance could be leveraged to eventually form a world government with local legislatures. This should not be forced but rather encouraged organically in my opinion. But benefits of this would be to mitigate against local legislatures behaving in an adversarial fashion non-constructively, and thereby reduce the need to be more careful about research and development of essential technologies critical for mitigating other risks.

Devtober – Retrospective

October 25, 2019

I have decided to call a retrospective early, as it is clear to me now that I am unlikely to use the remaining time this month to focus on my project – and the next span of time that I will likely have free will be mid November.

The Good

  • Got started. Great productivity hack!
  • Managed to prototype asynchronous join on my local machine
  • Understood a bit more about server non authoritative for book-keeping multiple sessions
  • Great synergy between GodotGetaway and my project
  • Learned about other work people are doing


  • How could I do this better next time?
  • What are the key directions for further progression?
  • Should I use Jira for tracking work next time?
  • What should I learn for next time?
  • Should October be the only productivity hack month I observe? How frequent should these things be?

The Bad

  • Often ran out of energy even while observing Devtober
  • Didn’t get as far as I hoped
  • Other commitments got in the way a bit

The Bad. Let’s think about the bad first. It is clear that working each and every day is not workable. I think therefore that some form of discipline – having at least one rest day, and maybe two – is important. I would say that Sunday should be a rest day, and maybe Wednesday too, to space things out a bit. (Action 1).

Also, perhaps sometimes it is okay to call Devtober over early.

Questions. I think to do better, it would be useful to use Jira for tracking (Action 2), and to also perhaps pre-plan prior to Devtober roughly the work that I hope to achieve and maybe prototype it a bit (Action 3). The key directions for future direction are to work on server non-authoritative. This should be tracked in Jira, and I should get a cloud instance for this. In terms of frequency of productivity hack months, I’d say no more frequently than 4 times a year, and possibly just 3 times. Maybe January or February can be my next productivity month. (Action 4).

The Good. Devtober indeed worked well as a productivity hack. I also solved a couple of preliminary problems with my project. I should celebrate these successes when I have them (Action 5). I should also share the excitement with friends and/or other like-minded souls (Action 6). Finally I should continue to learn about Godot programming and other things in my spare time (Action 7).

Actions (for next productivity hack month)

  • Sundays and Wednesdays to be rest days
  • Use a cloud instance of Jira for tracking and planning work
  • Pre-plan prior to next productivity hack month
  • Next productivity hack month to be January
  • Celebrate successes when I have them
  • Communicate with others and do things in community if possible
  • Continue to learn about Godot programming and other things in my spare time by kickstarting courses, and doing said courses

Devtober 18-20: the slump

October 19, 2019

Yesterday I did another GodotGetaway video on border walls for the city per that tutorial series.

However, in terms of the project, I haven’t found the time for it over the last few days. I would like to find time to at least get started on some of the api server stuff mentioned a few posts back. Anyway, we’ll see if I do prior to the end of October.

Devtober 16-17/10

October 16, 2019

The last two days I’ve been short on time. No progress.

Devtober 15/10: Learning: Pausing the game

October 14, 2019

Audited yet another video for GodotGetaway today. Learned about how to pause the game until all players are ready. No progress to speak of on anything else as yet. Although, maybe it might be useful to handwave my way through logical first steps.

For players A, B, C, and server S:

When player A starts a new game as host, that should be registered on S as a new session with ip of player A, and said ip marked as host: true.

Task 1: When players B, C want to join a running game, they should see ip(A) as an option served by S and be able to select and join within the game client.

Task 2: On join, a new client with ip(B) should be associated to the session with host ip(A), i.e. { session_id: 1, players: [ { host: true, ip: ip(A) }, { host: false, ip: ip(B) }, { host: false, ip: ip(C) } ] }.

Task 3: The server should receive a signal from clients if the server disconnects and update its model { session_id: 1, players: [ { host: false, ip: ip(B) }, { host: false, ip: ip(C) } ] }

Task 4: The server should randomly select a new player as host { session_id: 1, players: [ { host: false, ip: ip(B) }, { host: true, ip: ip(C) } ] } .

Task 5: The server should propagate this decision to the client ips connected to the session.

Task 6: player C should start a new game with the last game state, and player B should automatically be reconnected to the new game.

Devtober 14/10: Learning: Networked city generation

October 13, 2019

I completed another video in the GodotGetaway course today, on Networked city generation.

Not much more to report!

Devtober 13/10: Handling server disconnection

October 12, 2019

I’ve spent a bit of time today and yesterday attempting to handle server disconnection purely on the client side. However, I believe that this is insufficient and doesn’t really work.

Indeed, if the server disconnects, we need to create a new server from remaining peers and re-establish the game.

This is where the heroku server would come in handy. So on server disconnect, each client should reach out to the rails api server, and then the api server should randomly select one of the remaining peers. After that, said peer should create a new server, and other peers should be sent data as to which ip & port to connect to after the server is established.

  • So A disconnects with B and C.
  • B and C can’t see A. Then reach out to server S
  • Server S selects peer B. Sends signal to B
  • B starts a new server /w synced data at B
  • B sends a signal to S when server ready
  • S sends signal to C with the ip of B and the port of B for new server
  • C joins server at B with ip & port as specified from S

So this is a bit more complicated and will require some finesse. However it should be achievable.

Devtober 11-12/10: Whitebox prototype asynchronous join working

October 12, 2019

Devtober 10/10: Rest

October 10, 2019

Rest day today (yesterday?).

Devtober 9/10: chance of skyscraper

October 9, 2019

Today I audited another video in the GodotGetaway course. No time to touch the project itself though. Maybe tomorrow.