Project Decorum - Wallet Release



You may have some fresh, new, FastCoin? :slight_smile:

Can anyone send me something too, please?


What’s your name to send tokens to?


My name is: traktion


Couldn’t you have picked something more obvious? :wink:

Apologies - I thought I’d tried that already, but apparently not! Enjoy your NVST. They’re like Safecoin Version 10!


(20 characters)


I made a wallet and a name but need to find more time to create some coinage! Public name is always “Nigel”


I created one “Wallets”: pоlpolrene (this by the way is NOT @polpolrene and a potentially a way to steal people their SAFEcoin, by just posting a name that looks exactly like polpolrene, maybe your web of trust can help here or that certain keyboard types/languages inputs are not accepted in the wallets) after that I created two “Names” pоlpolrene and pietje.

@Seneca I have a few questions, here I created/received 10000 Concoins in the pоlpolrene Wallet on Name pоlpolrene:

Here is send 0.1 Concoins from pоlpolrene to pietje (pietje was also asigned to the pоlpolrene “Wallets”)


Strangely now the pоlpolrene Wallet got 0.1 Concoins and the 9999.90000000 in the pоlpolrene wallet is in limbo.

So you can send money to your own Wallet in the current setting and destroy/hide the money that you should have left in your wallet, after the transaction.

Here I made a second transaction from pоlpolrene 0.01 Concoins to pietje

When I return to Wallets I get this (I also got this the first time)

I hope/know that this wouldn’t happen in the real world, but it was just a experiment, this is a experimental wallet after all. :stuck_out_tongue_closed_eyes: Sorry @polpolrene for the name abuse, but I’m trying to think a little like a hacker thinks to improve our wallets.

Now that I think about it, those links that I send you look an awful lot like an blockchain/explorer

Yeah yeah now I do realize that every Name needs to be assigned to it’s own Wallet


I can’t comment until I’ve spoken with my legal team about this :joy: .

Isn’t that wallet name just a local thing? I can rename my Bitcoin wallet “Dogecoin” for example but if it’s only me to see that locally there shouldn’t be a problem.



I still own the polpolrene public_id on Alpha 2. My wallet is called My_wallet. So to steal my tokens you need to become the owner of the public_id polpolrene. Which is as hard as hacking safe://polpolrene

So as far as I know you can’t steal someone’s tokens that way. You really need the public_id for that.


One way to avoid this name abuse would be for wallets to use a dedicated service. So safecoin.polpolrene would be your wallet address, which means any wallet can transact with polpolrene’s Safecoin wallet and know it was the polpolrene who owns that public I’d.


If you copy/paste this pоlpolrene
You’ll be able to register it again as an publicID. It’s something like this story

But this is more like a social hacking that has been going on in the Ethereum space, for instant they post an address or website name and people copy it or click on it and send their funds to the wrong address or get their privatekeys stolen by entering it into a phishing site like happened many times with Myetherwallet exact clones.

Purely using another language’s keyboard your name can look exactly the same while it’s not. Maybe seneca’s web of trust could help, it could potentially have a Ripplesc feature like borrowing money from close friends and family.


Yes, indeed, it has no meaning except for in the UI. It’s just meant to be a human friendly wallet identifier.

Thanks for reporting this! Transacting from and to the same wallet is an edge case that we haven’t taken care of yet.

At the moment that is actually happening, but we’re not showing it in the UI. When a public ID is given, such as MyId, then it is prefixed by decorum. resulting in decorum.MyId. When associating a public ID, we’re storing a file called decorum-wallet under the decorum service of the specified public ID. However, the public container does not contain any reference to this folder yet, as I’m unsure what the convention is with the public container and NFS.


They arrived! Your post made me lol! :smile:


So what’s the consensus guys? Buy, sell, love it, hate it?


Umm… what’s the subject?


The wallet. Anyone done a YouTube walkthru or anything?


Bit early for that - it’s not operational yet


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