Project Decorum: DECentralised fORUM (and protocol)

@seneca, glad for your motivations, it is needed The decentralized forum; Where else were we going to continue the discussion? SAFE Network, a Decorum is paramount.

Hope there will be a self-moderation, and finally PMs that are private :sunrise:


Great work!

So to reply to a topic, do I need to burn some coins for that? And what If I bought coins for a cent, and they went up 10 times or so, would that make posting and replying more expensive?

This is cool, but again, what if the coin became more or less expensive? At the price of 1 cent, maybe 50 people like the post so the topic is on top of the list (burned 50 cent). But after a few days the coin goes down a lot in value, and now we have 80 likes but only 40 cents or so, so the older topic with less “likes” is still on top of the list?

1 Like

No, just one PUT usually, to upload the reply to the SAFE network. Decorum doesn’t add any cost to replying, the coin is used by Decorum for that second type of endorsement only.

Yes that can happen, but all coin endorsements “decay” in weight anyway as new coin endorsements are given in that collection (like a forum category). So short term fluctuations happen and may infuence the score balance for a bit, but on the longer term it all balances out as older endorsements decay more and more.


So it’s a pay-per-like model? Where the payment is probably so low that you can like a lot for a cent, but which is to expensive for bots due to the cost of PUT’s and the cost of liking their own spam. That’s quite cool :yum:.

But the coins get burned once you like something? No way of getting them back? No recycling? And I can change a setting to decide what I pay-per-like? like 0,5 coin or so?

Kinda, remember that these coin “likes” are in competition with other coin “likes” of other content in the same category, so whether a particular amount of coin “likes” is a lot, is relative to how much coin “likes” other content in that category (recently) received.

Indeed.[quote=“polpolrene, post:109, topic:6119”]
And I can change a setting to decide what I pay-per-like?

Yes, or you can just fill in the number of coins you want to use in input field at the moment of endorsement.

I am not sure if alt-coins will be divisible in SAFE. No promises there.

But remember that there’s also the other type of like, which you’ll probably use most of the time in your own communities. If for example this SAFE Network forum we are on right now was on Decorum, you’d probably be in almost everyone’s web of trust on here, because you are a legitimate member and no spam bot. Then you can just use the trusted “like”, which doesn’t cost any Decorum coins, and almost everyone here will recognize that “like” as legitimate.


This is just my personal opinion (and I may be wrong), but I see the coin “like” as something that will mostly be used by larger movements and organisation that will likely have a budget to use them.

Envision for example a gaming forum where a member writes about an amazing experience in a new game. Regular members of that community will mostly endorse it with the “trusted likes”. But if the publisher of the game in question notices that post, they will use the coin “likes” to give that post an extra boost.

The publisher doesn’t have another option, because spamming fake identities is useless, they won’t be able to get into the web of trust of that community.

I hope that illustrates how the sybil attack is solved with this system.


This is very exciting @Seneca thank you. Can’t wait to hear more and help you build this.


Edit: These details about crowdsale are outdated, supply is now 50 Million and inflation rate per doubling 10% (5 million)

Because the endorsement coin is permanently consumed when it used as an endorsement, the coin supply cannot be static, or else the coin would go extinct at some point. Some time ago I wrote about how SAFE alt-coins can be mined to have a flexible supply while still constraining inflation. This is an excerpt of that post that explains how this “mining” differs from blockchain mining:

If you have questions concerning that process, please read the entire post.

Also, please note that the numbers below may be subject to change.

100 million coins will be pre-mined and sold in the crowdsale. They will be divided proportionally over the crowdsale participants to the contributions of each . The crowdsale will last 5 weeks. In the first week contributions will get a 20% loyalty bonus, in the second week a 15% bonus, in the third 10%, in the fourth 5% and in the last week there won’t be a loyalty bonus.

At the end of the crowdsale it will be calculated how much was paid for every sold coin (total income dividided by 100 million), which is then multipled by 10, and from that number a base mining difficulty will be derived. This base mining difficulty will be put in the mining algorithm in such a way that the first minable coin (coin number 100,000,001) will have that difficulty. The algorithm will increase the mining difficulty for every coin so that for every 20 million coins mined, the difficulty doubles:

Formula: 2^(0.00000005*(x-100000000))

The idea behind multiplying the price of the pre-sold coin by 10 is to make sure that there won’t be any significant inflation from mining until either market price has increased by a factor of 10, or many years have passed and computer power has become cheaper.

Deriving the base difficulty from that number will be done using BTC mining data. From this chart it becomes clear that nowadays about 1,100,000,000 GigaHash per second is generated in competition for a reward of 25 BTC about every 10 minutes. 25 BTC is currently worth 10,400 USD. We divide this number by 10 (minutes) * 60 (seconds in a minute) to get the USD value per second: 10,400 / 600 = 17.33 USD per second.

Now we can hold that circa 63.5 billion GH has a value of about 1 USD. So if the presale coins were sold for say, 0.001 USD each, the base difficulty is set to 635 million GigaHash (0.01 USD).

This base difficulty doubles every 20,000,000 coins, to off-set the effect of Moore’s law. Right now computing power doubles about every 2.5 years, so all other factors being equal, the mining inflation rate should be about 20% per 2.5 years.

Of course, factors won’t be equal, and the main factor that influences the mining rate will be the price of the coin. If the coin goes up in price, then mining profit margins increase so there’ll be more inflation. If the coin goes down in price, mining profit margins decrease and there’ll be less or even no inflation at all until the price has recovered.

Also, the coin is consumed when it’s used as an endorsement, so that contracts the supply. I envision that the coin will tend towards a price point where the contraction of the supply due to consumption roughly matches the inflation due to mining. Then there’s no netto expansion of the supply, until the coin price leaves it’s equilibrium and goes up significantly.

Because the base mining difficulty is set to about 10 times higher than the pre-sale value, the supply will likely only contract at first. When serious mining starts, the coins of the crowdsale partipants may already be up to 10 times up in value.


This is really quite elegant from what I can see.

The WOT model seems very workable. Not hard to establish, but hard enough to make it easy to nuke spam, if the community wishes. The reason I emphasize “if the community wishes” is that for some applications, a spammy free-for-all might be desirable, as in some sort of wild and woolly open-bazaar smorgasbord of whatever. But for a community that wishes to be much more discriminating, it can not only easily curb people and bot spam, but make such intrusions decidedly unprofitable, without having to spend coin to do it.

Seems that the scale between the free-for-all groups and the closed, invitation-only secret group is seamless, depending upon the like-mindedness of the participants. The dynamic group dance of individual choice. Brilliant.

On the other hand, having paid likes makes bridges possible. Don’t have connections into a community who you think would like what you have to offer? Pay some coin for paid likes to get attention, then gain WOT support if you really are a desirable connection, in the eyes of THAT community.


Thanks for the support guys!

I got a question privately of how the mining difficulty formula works exactly, so here it is:

coin’s difficulty = base difficulty / 2^(0.00000005*(coin’s identifier-100000000))

And the base difficulty used in the example is (1 / 635000000000000000). So you have to generate 635000000000000000 hashes on average to get the first coin. Yes, that’s a lot, because by taking BTC hash rate as an indicator for hash price, we’re talking ASIC hashes here.


Looking good @Seneca

When a coin is “consumed” is it deleted? Owner changed to? or?

1 Like

So this going to be an onmi protocol 1:1 crowdsale for BTC and not a sale that accepts Safecoin or MAID?

Very cool, so glad to be seeing a WOT implementation on SAFE! Have you considered your application of a WOT outside of Decorum, but as a “plugin” for all other apps? The WOT is definitely something that a majority of websites could use, IMO, from marketplaces, to services, to social networks, and I would love to see it implemented elsewhere, as well. In fact, the same identity could be used across all apps, if so desired, instead of making a separate one for each.


I honestly wouldn’t know how to do it otherwise, other than making it a closed source project (bad idea). The app/website is just an interface to the actual data, which belongs to the users, and the protocol is open. So every developer can make use of these systems with their own apps.

This being a SAFE project, I definitely want to accept MAID. I’m not sure about accepting BTC as well, not because I dislike BTC but because accepting two currencies gets messy when converting their values to see who gets how much, and I don’t want any drama.

Also, it looks like the Omni “crowdsale” feature assumes you want to give X amount of new coins for Y amount of existing coins, while I just want to work with a fixed amount of new coins spread over all participants. So it looks like I’ll have to do it manually (register the new coin, get the fixed amount myself, then distribute them manually to everyone).

It’s owner value is changed to a value that hasn’t got a known private key counter part (hash of the content it is attached to). If people hack the (client-side, ofc) source code (easy to do) and change that part, other clients won’t count that coin as an endorsement (so it’s useless to do that).


Yes that’s true, was thinking more about the structure of the data more than anything. Do you have any implementation details to share about this? A full-fledged WOT would have massive ramifications for the decentralized SAFE network. I’m really interested in how you would do it.

From the top of my head, I’d say you’d be using SDs where the type is the person being “trusted”, and the identifiers consisting of all the people that have placed trust in that person. Is that the general idea? How would the “scoring” be done, as usually a WOT includes various degrees of separation in its algorithms?

Check with @dallyshalla. He did both for the SEC sale. Not sure how difficult it was, but he pulled it off without upsetting anyone, as far as I know.


Yes, please accept both if you can. I think parting with some BTC is easier than parting with MAID :slight_smile:


For performance reasons, I would let each identity maintain one big list of (public) actions they performed on other identities. Each identity would periodically grab the lists of all identities in it’s own list above a certain score threshold, which is then merged with their own list (hashmap merging and lookups are very fast). When a piece of content with signature endorsements is encountered, each corresponding publicID can be looked up in the merged list, and if present and above a certain score, the endorsement is counted. I think it should be possible to track about 10.000 identities in a single MB that way.


I think “classic” SD will be insufficient for many of the use cases in the long term; it would be awesome to have a skinny little data type just for storing references. This would do away with the need for these clumsy workarounds.

These references wouldn’t even need to be mutable, and their address (which matters only to determine storage location) could be computed from their content. They would have a fixed size (just a few hundred bytes) so their storage and lookup could be highly optimized.

It’s impossible to search SD for content (e.g. the references they may contain) so there’s no way to say “I want the tags belonging to this document” or “documents with this tag” unless somebody aggregated them (relying on which becomes a SPOF.)

If we had a very simple data type for [owner, category, label, reference, signature] that could be searched for a combination of owner, label, reference, it would be trivial to ask questions like “stuff tagged by this person” or “stuff tagged by this label” or “tags by this person for this document.” This could be the basis of many different applications, including simple tagging, search engines, RDF triplestores, WoT entries, etc

(the “category” field above is just a way to let one owner come up with independent sets of labels)

In my semantic search feature idea I also suggested a fuzzy search for the “label” in the above scheme: there are ways to compute (or manually assign) binary tags where values with a small Hamming distance (“XOR distance”) depict semantically similar content, which would allow for “search by example” (documents about related subjects, similar images, …)


This is why there are reserved types and chat of a domain specific language (next step). Ultimately I would love to be able to have something as we do for publishing web sites, but semantically. So we have a reserved SD type that acts as we wish but demands tags to be filled in.

There is room for this for sure. Please keep chipping away at this one, it’s important.