Project Decorum - Wallet Release

[bochaco]

@bzee

Initially our wallet did not conform with this as we were storing wallet data directly under the public ID, causing the WHM to get stuck after our wallet was used. By storing the data under a file, conformity is ensured, although storing such data using a file does not feel like the ultimate solution to me.

Hi @bzee, I’m not sure how you are exactly storing the wallet now, but you don’t really need to store it in a File as I get you suggest it, e.g. the email app follows the same convention as the WHM but the email inbox is a MD (with random address) referenced from the services container, i.e. if your email ID is myprofile.mypublicid there is an entry in the services container for the public ID mypublicid which key is myprofile@email (@email is a postfix we choose for convention for emails) and its value is the serialised MDataInfo. If a webpage was published by WHM on the same public ID and service name there would be another entry with emptty postifx (no postfix is assumed to be safesite service), i.e. an entry in the services container with key myprofile and its value is the reference to the webpage NFS container with all files.
Therefore, you can do the same and have an entry in the services container (with a postfix chosen for your service type) which is mapped to a MD rather than a file, obviously you’d need to avoid using the NFS emulation for doing this, as I suspect that’s what you are doing and this is why you say it’s stored in a file? I hope that helps.

[bzee]

Thanks for your suggestion!

@bochaco

… no postfix is assumed to be safesite service …

…

Therefore, you can do the same and have an entry in the services container (with a postfix chosen for your service type)

If I see correctly, at this moment the WHM hard coded that convention only for the email service! Not for other services like Decorum’s wallet:

maidsafe-archive/safe_examples/blob/e985e02ab3efd114f06ccd80e7cd8f3331c059cf/web_hosting_manager/app/safenet_comm/api.js#L250

So, still, for us there is no way to make sure we’re conforming to whatever the WHM is doing without using the NFS structure. This is why I would like to request @maidsafe to come up with more elaborate standards that developers can follow so all apps are ensured work together.

@bochaco

obviously you’d need to avoid using the NFS emulation for doing this

That is what we did, and it broke the WHM. Then we started following the available RFCs and SAFE examples’ code more closely, and ended up with the current solution. The RFCs do not mention a postfix, only that “each service name points to a Network DataIdentifier”.

[happybeing]

@bzee

This is why I would like to request @maidsafe to come up with more elaborate standards that developers can follow so all apps are ensured work together.

I’ll be entering this fray soon too (for a Solid service) so guidance on how to avoid breaking things like WHM here would help.

@bzee can you say a bit more about what precisely the WHM couldn’t cope with? Maybe it’s the WHM that needs fixing here, in which case I suggest you create an issue if you haven’t already.

[bzee]

@happybeing

guidance on how to avoid breaking things like WHM here would help.

Our solution was to follow the RFC. To me, it is the guidance, and therefore it’s important for it to cover these use cases as they seem fairly basic.

@happybeing

@bzee can you say a bit more about what precisely the WHM couldn’t cope with?

The WHM follows the RFC. The RFC dictates that the values in a public name MD should ‘point to a Network DataIdentifier’. We initially did not put a ‘Network DataIdentifier’ (XOR) as a value, but the Decorum wallet data. That’s what broke the WHM, as that data is not a valid XOR.

@happybeing

Maybe it’s the WHM that needs fixing here, in which case I suggest you create an issue if you haven’t already.

The WHM works fine. The only thing that bothers me, is that it makes a single (arbitrary) exception for the email service by filtering out service names that contain @email. This is not mentioned in the RFCs!

This is why the solution of @bochaco would be unsuitable as the @decorum postfix is not recognized by the RFC nor the WHM (also causing it to crash).

[JayM]

Hi Seneca,

I would like to contact you using telegram/email. Is that possible?

Thanks.

[bochaco]

@bzee

If I see correctly, at this moment the WHM hard coded that convention only for the email service! Not for other services like Decorum’s wallet

You are correct @bzee , and that’s the issue, the WHM should filter out not only services with the email postfix but all with non-web service postfixes, i.e. filter out all services with a postfix, thus the code you shared is where the bug is. The proposal by this convention is that a postfix is conformed of @ sign followed by the name for the type of service, so you could effectively have @decorum as a postfix, we just need to fix the WHM.

I think this convention came later after that RFC was proposed and implemented, I agree it would have been a good idea to also describe it in that RFC. I do remember that we came up with this proposal when we were migrating the email app to make use of MutableData API, and that’s when we realised we would like to allow different type of services under the same service name.

[joshuef]

@Seneca

Test driven development

Even though fully automatic testing doesn’t seem to be an option for us right now (no headless browser support yet), we’re looking into applying “semi-automatic” testing where some minimal human interaction is required to run tests.

@Seneca, While there’s still no true chrome headless in electron as yet, we’re starting to automate some tests for the browser using spectron.

And while this isn’t baked into peruse nor safe-browser yet. You could potentially setup something similar to get your tests automated. Spectron does allow you to interact with the webpage as well as the browser UI itself, so you should be able to get most repetitive tasks automated.

Down the line it would be good for us to enable this in a more integrated fashion with the browser; although I’m not sure how that would go as yet.

[bzee]

@bochaco

I think this convention came later after that RFC was proposed and implemented, I agree it would have been a good idea to also describe it in that RFC.

That clears it up, thanks for explaining!

Will the RFCs be updated, or is there another source that app developers can get these conventions from?

[bochaco]

@bzee

Will the RFCs be updated, or is there another source that app developers can get these conventions from?

I would say yes, they’ll need to be updated. On the other hand, it also depends if we are gonna consider them to be similar to what the IETF RFC’s are, i.e. they work not only as a way to explain proposals for changes but also as a reference and standard. At the end of the day all this need to be referenced from the dev website that we will eventually have, either as RFCs or design documentation.

[Nigel]

Wanted to dig up this thread as I’m curious how you guys are progressing!? Any other module teasers coming?

[sam123]

Wondering the same thing

[Lackys]

It’s strange that no info for weeks…

[Nigel]

These guys deliver. This module alone is huge, there are few out in the open doing what these two are doing so be patient. It is nice to hear from them but they like comments here and there, I take that as a nod to that they’re around and busy based off of their character in the recent and less recent past.

[Lackys]

I think developer gone like project n99

[riddim]

thats crap talk

@bzee just postet yesterday the last time and is obviously very actively following everything here

Extensions in Firefox 59 | Support for Decentralization Protocols

From Extensions in Firefox 59 | Mozilla Add-ons Community Blog Support for Decentralization Protocols Mozilla has always been a proponent of decentralization, recognizing that it is a key ingredient of a healthy Internet. Starting with Firefox 59, several protocols that support decentralized architectures are available for use by extensions. The newly approved protocols are: Dat Project (dat://) IPFS (dweb:// ipfs:// ipns://) Secure Scuttlebutt (ssb://) One of my main concerns for t…

how about being a little bit patient first and do a little bit thinking/research before randomly accusing people of something

ps: but yes - just a short note that you guys are alive @Seneca and @bzee would be nice - and a quick statement on how you plan on progressing (e.g. focusing on some module now until the api is stable enough to do serious development at that other edge of the project)

[bzee]

I was expecting @Seneca to respond soon enough. There is no reason to spread FUD like that. Nevertheless I understand we should let you know what we’re up to.

For the time being, I would like to refer Harmen’s last update:

@Seneca

So I’ll just say that you shouldn’t start holding your breath already for major strides forward. At the same time we plan to gradually open up our activities though (this update being an example of that).

There is not much to add to that post. Currently I’m graduating, and have less spare time for the project. I don’t consider it my job to give updates here, so this is all I will share for now.

[Seneca]

@Nigel

Any other module teasers coming?

This plan still aplies…

@Seneca

We have an internal roadmap to develop the following core Project Decorum features in this order:

Identity and contacts management
Private messaging
Topic/threaded discussions
Endorsements and moderation
Refactor and integration of the wallet module

…as well as the mentioned areas for improvement. The run-up is a bit long, that’s all. In addition I’m working on a recruitment plan. I also need a break now and then, plus I don’t feel the need to always answer every post in short order (dirvine has really spoiled us all in that regard). I know we could hire someone to do this, but then you’d just be strung along and be fed non-answers during slow times. I’d rather give rarer but more sincere updates myself, at least for the time being.

@riddim

just a short note that you guys are alive @Seneca

Definitely alive, still commited.

@Lackys

I think developer gone like project n99

If that was the plan we never would have bothered with the module release.

Thank you @nigel and @riddim for the support.

[sam123]

Harmen,

Thanks for the update.
I agree with you no need to answer every post.
I was just wondering if you can give us a monthly or even bi-monthly update if possible
Take care
Sam

[wize83]

It has been a month already and I agree with you. Although it’s all about the technology, the facts are that Bittrex is delisting coins and even PDC’s mother MAID will be delisted coming March. Reasons for periodic updates:

1. Is the project is still alive. Sounds simplistic but we just won’t know when there’s complete silence!
2. Let potential investors know this is a great project, which might create some needed volume to stay relevant on Bittrex.
3. To know what the devs are up to! We are all here because we love the project, why not tell us more about the latest developments. Let us know something so we can collaborate as a community. It’s much more fun to share the joy of this great technology.

[Lackys]

Will we see @Seneca at the SAFE DevCon?