Project Decorum - Wallet Release

Pretty neat Decorum’s wallet, when you create a PublicID in the wallet it’s also created in the Web Hosting Manager. I was planning something similar by integrating all the Web Hosting Manager’s feature in our wallet. @luandro this is what we were talking about, how to make the desktop WHM obsolete. :stuck_out_tongue_closed_eyes:


This is a side effect of both applications following the same standard. 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. Perhaps more elaborate standards (@maidsafe) will appear once other developers require more complex use cases (e.g. ways to store data under public IDs without NFS).


Is there a roadmap/ETA for pre-alpha software release besides the wallet?


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

  1. Identity and contacts management
  2. Private messaging
  3. Topic/threaded discussions
  4. Endorsements and moderation
  5. Refactor and integration of the wallet module

By reviewing the development process of the wallet we identified the following three areas where we want to make significant improvements for the next releases:

  • 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.
  • SAFE data model and transmission
    The wallet turned out to generate many redundant requests to the SAFE Network. Often two or more consecutive requests for different data would interact with the same container/MutableData, causing it to be fetched multiple times, introducing unnecessary delays. Since we expect the latency to be significantly higher on the real SAFE Network than in the late Alpha’s and testnets we’re designing a model to handle this more elegantly. We’re considering to always update the store (the app’s local database) with all the data present in a fetched container/MutableData, plus timestamping this data when that happens so the actions generated by the web-app can decide on a case-by-case basis if the data in the store is still considered fresh enough or if a refresh from the SAFE network is warranted.
  • Data sanitation
    We’re going to analyse if there are currently any obvious vulnerabilities to attacks by malicious user-generated content that our app loads into the browser. If found we will attempt to find data sanitation solutions for them. We are hardly security specialists, so as SAFE moves closer to it’s v1.0 release some actual professionals should get involved. We want to take any necessary basic measures in the meantime to hopefully prevent widespread abuse that could result in loss of confidence in this project.

We’re not comfortable giving ETA’s for the same reason as MaidSafe. We’re trying to step up our game now, so we will take some more time than if we would rush ahead at the same level of quality as the wallet. 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).


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.


Thanks for your suggestion!

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:

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.

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”.


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.


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.

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.

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).


Hi Seneca,

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


1 Like

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.


@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.


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?

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.


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


Wondering the same thing


It’s strange that no info for weeks…

1 Like

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.


I think developer gone like project n99

thats crap talk

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

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)


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:

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.