Team organization structure proposal

Direct Connect is very loosly organized and has always been. There are a few people that control resources, be it websites, software or hubs. However, the idea of a strict hiearchy is by many appalling and that is why there is no designated ‘boss’ person. Indeed, simply appointing someone is directly not possible because of the structure of developers and projects. There is no one that decides what to do or what must be done. Everyone is a volunteer and pitch in when they can and want to. It is why I think that we should not focus on a person that ‘delegates’ tasks to people, rather we should focus on what we want to accomplish and what we want to do in the community.

That is why I propose a new type of organization breakdown, focusing on work area and interest area, ‘teams’ or ‘workgroups’. The intent with the teams is to provide a clear message to others what we’re working on and how they can help for that group. For example, a person that is interested in security can provide information in the ‘security team’ whilst not feeling a requirement to participate with the interoperability of software. The point of the team is not to say “these people have to produce content for this team”, but rather “these people know some stuff that pertain to this subject” and serves as an encouragement for them to provide content (documentation or software etc). The purpose with all teams must be to better the DC community in some way. My hope is that participation in a team is meant to spur people into working on that team’s issues and future (i.e. a commitment to oneself). Of course, anyone can submit information and help a team. A clear intent on what the community or team needs can allow new people to help with the community.

My proposal is also to have a team leader that tries to encourage other participants in the team to provide data. Do note that I do not mean “hey, do that” but rather “hey, I think you have knowledge about a subject, could you check out if it’s something you’d be interested in and write anything on the subject”.

By the way, teams aren’t meant to be static: they can change and new ones can be introduced and old ones can be removed.

In addition to the team leader, I propose that teams have a cyclic report on what been done in the past X. For example, if there has been lots of stuff going on with security (be it documentation or even discussion) in the past week, it should be lifted in the blog and forum, so we can have summaries of decisions or interesting avenues.

Teams I have thought of:

  • Security – Overarching adressing security
  • Cryptography – A subteam for security that focuses on math and cryptography itself
  • Software – Overarching addressing software in terms of clients, hubs and others items
  • Interoperability – A subteam to software that addresses interoperability issues that arise between software
  • Protocol – Addresses the needs of the protocols both in terms of software support but also in terms of documentation and standardization
  • Infrastructure – Addresses needs in the infrastructure of projects

I have only created an intial description of security and cryptography (below) but I will add more later on. Also, I’ve created forums for each of those items at dcbase.org


Team: Security

Purpose: Investigate and publish items relating to security.

Description:
The team will gather and inform the community on any security related issue that arises directly within DC or if external data that may be of interest for the DC community.

The following are items addressed:

  • Auditing of attack vectors:
  • Protocol messages
    • Content passed over implementation boundaries
      • File list
      • Hublist
      • Other messages that others must react to (e.g., chat messages relating to magnet URI parsing)
    • External sources of information (URIs)
    • Certificate management
  • Auditing of protocols:
    • Message structure and content
    • Providing information for protocol parsers (wireshark, profilers, sniffers, packet-shapers)
  • Auditing of implementations:
    • Spam/Flood protection mechanisms (and other DoS-related content)
    • XML parsers (file list, hublist, zip-bombs)
    • Protocol message parsers
    • Hammering of hub after kick (reconnect timer etc)
    • External library implementations (SSL, BZIP, XML etc)
    • Source references (RF field etc)
  • Other points for audit:
    • Hublist retrieval (distributed etc)
    • version.xml retrieval (distributed etc)
    • Audit of DC architecture
    • Nature of data broadcasts
    • Hub controls content
    • Hub is fully trusted
    • Distribution of hub/dns etc
  • Post and review of CVEs
  • Security companies contact
  • Audit and review external security related reports that relate to DC

Team: Cryptography

Purpose: Investigate and publish items relating to cryptography.

Description:
The team will gather and inform the community on any cryptographic issue that arises directly within DC or if external data that may be of interest for the DC community.

The team will provide a description of the cryptographic solutions currently employed. The team will also provide information about cryptographically related content such as hashing, as the latter may benefit from analysis of the former.

Functionality that will be included as protocol extensions will be discussed with the appropriate protocol team.

The team will inform the community as clearly as possible, providing necessary information for cryptologists as well as for the lay person. A report of the current discussions and results will be published on a regular basis (monthly if there have been any new content).

The crypto-team is related to the security team. However, the former’s job is to focus any cryptography while the latter is focused on general security related content. As such, the security team will only address cryptography based on the crypto-team’s reports.

Software that influence or validates the cryptography functionality will also be provided.

The following are items addressed:

  • Certificate management for client – client and client – hub connections
  • Hash management
    • Tiger Hash
    • Potential successors to Tiger (Tree) Hash: SHA-2, SHA-3
    • Protocol support with ADC and NMDC
    • Implementation support
    • Sharing hash databases

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: