January 7, 2020

p≡p/SWIFT documentation project

The plan is to do a documentation project for p≡p for swift.

Documentation on 4 Levels:

  1. Project doc template / consulting product (rw-)
  2. Product description of network components (patrick)
  3. Technical description of network components (dietz)
  4. Technical specifications (kelly)

Aspects to be adressed on all 4 levels:

  • Functional
  • Technical
  • Network
  • Deployment
  • Operations

The aim is to keep “p≡p for email” and “p≡p for swift” as close to each other as possible.

Lets bootstrap a CCC Hackerspace Winterthur

  • foundation might financially support it
  • we need a space/room/accomodation
    • al least 60m2
    • Public transport is key
    • Cheap…
  • Sofia has a link, too

p≡p Philosophy Notes

  • A system is secure against an event if the event cannot happen.

  • Trust is needed where security is not there.

  • A security analysis is based on Attack Vectors.

  • Attack Vectors must be identified and removed.

  • If an Attack Vector cannot be removed there must be Detection and Mitigation of events, where this Attack Vector is being used.

p≡p is a privacy project. p≡p is delivering security whereever this does not harm privacy. p≡p relies on the security of endpoint devices. (Endpoint_security).
p≡p is a cost optimization project. We try to make mass surveillance as expensive as possible.

Adapter standardization


The idea is to have a C++ layer on top of the engine, to be used by adapters written in C++. The current idea is to use and extend libpEpAdapter for that matter.
Move all possible redundancies (common code) across adapters in to libpEpAdapter.
Everything that makes sense should be Code generated (e.g types, see engine branch gen_samples)

Portable C++

Adapter will use different C++ versions. The C++ version must be part of the build def of an adapter. The whole software stack has to be built using the native default system toolchain of the target env.
Therefore, libraries and code which is used on different target environemts, must guarantee identical behaviour, even when compiled using different C/C++ standard and compilers. So, for libpEpAdapter, the core problem is to define C++ coding standards and patterns that are portable across several different standards of C++.

Default C++ Standard

Today, we’ve at least C++ 11 on all platforms (z/OS has it). So versions before are not needed any more. When Windows has to be supported then CL.EXE sets the limit. When many different platforms have to be supported then there MAY be platforms with older compilers only.
Hence we’re basing on C++ 14 today for most projects.

Default system toolchain

The system default toolchain means, that we use only natively supported tools to build our projects. But we may have explicit version depencies (e.g. for a compiler) but it must be a natively supported version/implementation.

Portable C++

Identified portability problems:

  • Temporary object lifetime
  • Static init order (and resulting problems in concurrency)
  • POD-types (Plain-Old-Data)


  • auto_ptr are bad - shared_ptr are good
  • copy semantics are good

p≡p Engine

Here is a collection of notes about “The Engine” from the perspective of an Adapter dev. (heck)

Crytotech concept

The Engine has a variable backend concept using the driver pattern. Is implemented using dynamic binding. dynamic binding -> switching of drivers (backends) at runtime
dynamic linking -> no switching at runtime possible

String encoding

IN: UTF-8 NFC normalized
No unicode in engine

Memory management

you cant be guaranteed to just deallocate memory on a pointer using delete/free(), therefore:
pEp_free() is guaranteed to work always.


Here is a collection of notes about code generation from the perspective of an Adapter dev. (heck)

Version Control

Version control on DSL input files.
No version control on generated files.

Projects/Branches relevant for Code Gen

Engine Branches:

  • generate_api - nana neue DSL
  • gen_sample - sample for generating list types in C99 (linked list)
    • The same can be done for list types in C++
    • inspiration for codegen for C++ engine layer (libpEpAdapter)
    • z.B. c++ liste als iterable im C++ libpEpAdapter