Quote from: gimre on February 08, 2014, 10:37:03 AM

Quote from: jl777 on February 08, 2014, 09:55:28 AM

Quote from: gimre on February 08, 2014, 09:47:43 AM

Quote from: jl777 on February 08, 2014, 09:31:32 AM

I think we can verify the checksum of the running code for plugin matches the source code. Similar to signing of .jar files

Can you describe with details few things:

what the plugins could do and why they should be used
HOW they should be made? (that is should they operate on API or they should be REAL plugins)
what about people who don't want plugins? how limiting it (lack of plugins) will be?
How do you actually imagine this smtp plugin would work like (I'd like really detailed description along with use case description https://en.wikipedia.org/wiki/Use_case)
How do you imagine TRUSTing the plugins?

To be clear, I'm asking those questions, as most likely I will criticize the idea, once you answer to those questions.

I use the term plugin just as a placeholder, I am beginning to think it means different specific things to different people and is not the best term. When I say NXTplugin, I mean the code that is invoked when the forging node scans the AM data and finds that it is input meant for a specific plugin.

I have a bounty out on how to make plugins, it depends on what is needed to be able to do realtime checksum/hash of its code space in memory.

So you want plugins to be written in NXT VM? Have you seen specs that CfB posted. ATM it seems VM will only be able to do math (and from what I understood VM was supposed to be used for contracts only).

Something like NXTsmtp done in such VM is just "no no".

Regarding securify, I agree with what CIYAM said, there's no way you could trust plugins.

VM's output -> AM
That AM -> plugin
verification via indistinguishability obfuscator or simpler method if we can find one

Edit: NXTsmtp is ONLY a PROOF OF CONCEPT, not for actually sending emails outside of test cycle