Feature Request: Python Bindings for Enhanced Accessibility

[sunpihai-up]

Dear FIDESlib Developers,

Great work on building this high-performance GPU-accelerated FHE library! As an admirer of your work, I'd like to suggest a feature that could help expand your user base: Python bindings similar to OpenFHE-Python.

A Python interface would:

• Lower the learning curve for Python-centric researchers/developers

• Enable easier integration with AI/ML frameworks (PyTorch/TensorFlow)

• Accelerate prototyping of privacy-preserving applications

The success of OpenFHE's Python wrapper shows strong community demand for accessible FHE interfaces. Given FIDESlib's unique GPU capabilities, this could make accelerated FHE more accessible to broader audiences.

Would this align with your development roadmap?

Thanks for considering this suggestion!

[carlostriste]

Thanks for your suggestion!

We have been thinking about wrapping FIDESlib into the OpenFHE API, then OpenFHE API would be exposed to OpenFHE's python bindings as usual, but leveraging the GPU in the background in your server machine (for CKKS).

This would make CPU-GPU memory transfers transparent to the programmer too.

Would this approach fit your needs?

We are open to any feedback to enhance the usability of the library.

[sunpihai-up]

Thanks for your suggestion!

We have been thinking about wrapping FIDESlib into the OpenFHE API, then OpenFHE API would be exposed to OpenFHE's python bindings as usual, but leveraging the GPU in the background in your server machine (for CKKS).我们一直在考虑将 FIDESlib 包装到 OpenFHE API 中，然后 OpenFHE API 将像往常一样暴露给 OpenFHE 的 python 绑定，但利用服务器机器后台的 GPU（对于 CKKS）。

This would make CPU-GPU memory transfers transparent to the programmer too.这也将使 CPU-GPU 内存传输对程序员来说透明。

Would this approach fit your needs?

We are open to any feedback to enhance the usability of the library.

That's awesome! Thanks again to your team for contributing to the community.

[erikerlandson]

python bindings would increase community uptake. A nice eventual goal would be providing some higher-level utilities, similar to HEaaN.stat and HEaaN.sdk (which are not open source)