Skip to content
This repository has been archived by the owner on Jan 13, 2023. It is now read-only.

Masked Authenticated Messaging (MAM) Support #47

Open
todofixthis opened this issue May 7, 2017 · 6 comments
Open

Masked Authenticated Messaging (MAM) Support #47

todofixthis opened this issue May 7, 2017 · 6 comments

Comments

@todofixthis
Copy link
Contributor

Implement support for Masked Authenticated Messages (refer to https://github.com/iotaledger/mam.client.js/ for a reference implementation).

@todofixthis todofixthis self-assigned this May 7, 2017
@todofixthis
Copy link
Contributor Author

Moving back to "scheduled"; we're not ready to work on this just yet. For now, we will implement a PoC that uses the JS lib to do the crypto stuff, but that's not part of this GitHub issue.

ivoscc added a commit to ivoscc/iota-sensor-poc that referenced this issue May 21, 2017
Currently we call the JS implementation until MAM is implemented in Python.

See iotaledger/iota.py#47
@miili
Copy link

miili commented Jan 15, 2018

We should tackle this soon, wrapping the MAM Rust library (https://github.com/iotaledger/MAM)!

There are two options:

The two libraries are discussed here PyO3/pyo3#55
PyO3's approach seems to be more native and flexible, further it is said to be 15% faster

@todofixthis Apparenltly there has been done some work on the foundation https://github.com/iotaledger/iota-bindings with PyO3... how do the bindings come into play?

@todofixthis
Copy link
Contributor Author

todofixthis commented Jan 15, 2018

Awesome news @miili !

I think for PyOTA we should focus on a pure-Python implementation (with optional C extension if performance is an issue).

A solution that relies on Rust bindings sounds interesting (and I'd love to see it!), but I think it would be better for the long-term direction of PyOTA if that was implemented in a separate project.

@miili
Copy link

miili commented Jan 15, 2018

Should MAM for Python come in a separate package or be included in PyOTA?

@todofixthis
Copy link
Contributor Author

todofixthis commented Jan 16, 2018

My preference is to follow any precedent set by the Javascript library. If MAM gets included directly in iota.lib.js, then I think PyOTA should follow suit. If not, well, I don't think PyOTA needs to be monolithic anyway (:

If we end up with MAM in a separate project, though, I would still be happy to include it as an extra in PyOTA's setup.py (e.g., so that developers can install it via pip install pyota[mam]).

@miili
Copy link

miili commented Jan 16, 2018

Looks like the Javascript library will be wrapped around the Rust MAM library, through WebAssembler. See https://github.com/iotaledger/MAM and https://github.com/iotaledger/iota-bindings for Python prep work.

If we implement the Rust realisation as well, we can rely on a solid and well tested library. There will be one point of responsibility for many implementations.
I hope to have spare time in February and would like to takle this @HerrMuellerluedenscheid ;)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants