Understanding more about PyAPSI

[rnjailamba]

@LGro, great work with this wrapper. It looks well designed and possibly more user friendly than the base APSI library. I had some questions regarding your work

1. Does PyAPSI have any improvements over APSI or is just a Python wrapper?
2. Can you in short detail the process of creating this wrapper? (APSI does not seem to have a user friendly documentation and I believe you have already gone in the weeds to make sense of almost everything about APSI)
3. In the building and testing from source can you list the docker commands that need to be run to build and commands for the container to be tested.

Thank you very much in advance.

[LGro]

Thanks for reaching out ☺️

Does PyAPSI have any improvements over APSI or is just a simple wrapper?

There is no added functionality to the APSI protocol / the crypto. PyAPSI is just an attempt to expose APSI to a wider circle of developers and build something with it myself down the road.

Can you in short detail the process of creating this wrapper? (APSI does not seem to have a user friendly documentation and I believe you have already gone in the weeds to make sense of almost everything about APSI)

A bit of the progress is reflected in my exchange with one of the APSI maintainers in #1. From an architecture perspective, the most challenging for me to wrap my head around was the notion of channels for processing the different stages. What helped me figure things out is looking at the code examples in the APSI repository, like the CLI as well as the tests.

In the building and testing from source can you list the docker commands that need to be run to build and commands for the container to be tested.

Does looking at the contents of the Taskfile.yml already help you?
From the README example task wheel PYTHON_VERSION=3.10.4 this would yield a progression of:

# Build a base version that is Python version agnostic
docker build -f docker/base.Dockerfile -t pyapsi:base .

# Build in the Python specific stuff
docker build --build-arg PYTHON_VERSION=3.10.4 -f docker/py.Dockerfile -t pyapsi:py310 .

# Run tests
docker run pyapsi:py310

# Create a local output directory and copy the wheel that was built in the docker image to that directory on the host
mkdir ./dist/
docker run --rm --entrypoint cat pyapsi:py310 /tmp/pyapsi/wheelhouse/apsi-0.1.2-cp310-cp310-manylinux_2_31_x86_64.whl > ./dist/apsi-0.1.2-cp310-cp310-manylinux_2_31_x86_64.whl

Unfortunately, I just noticed that the second one fails due to what seems to be a SEAL version mismatch. I'll try to look into getting that running again but it might take a moment (#16).

In general, note that as reflected in #13 one remaining challenge with the current attempt of building wheel files is that there are hardware dependent optimizations compiled into APSI during build time that might be at odds with the target system. Even if one would be able to restrict this to the minimal subset of specialty features during compile time, this would mean that the folks installing the wheel do not benefit from all possible speed ups for APSI. An alternative approach would be to install from source and compile on the client side when PyAPSI is installed. While that would increase the compatibility and performance it would require a bit more complexity (most notably vcpkg) on the end user side. I'm not sure whether there is an obvious answer to this.

[rnjailamba]

Thanks for the guidance. I was able to completely test the CLI mode of APSI in labeled mode and it worked well (after some workarounds such as #16). I'll try to add more documentation to the main APSI repository soon.

Will dig into PyAPSI more in the next few weeks and will add/ ask anything new via the issues. Thanks again!