2021 Feature Requests

[lukebp]

This discussion will serve as a general purpose feature request thread.

[lukebp]

Feature request
Add a notification setting for every comment on every proposal.
Originally discussed in #878.

[lukebp]

Feature request
Add RSS support so that matrix bots can be created.
Orignally discussed in decred/politeiagui#733.

[lukebp]

Feature request
Serve raw markdown.
Originally discussed in #1464.

[lukebp]

The politeia section on decred docs was originally written for the git backend and needs to be refactored.

[lukebp]

Multiple choice, stakeholder polls.

[lukebp]

Proposal filtering by domain, start/end dates, or proposal status.

[lukebp]

Get rid of the split politeiad-politeiawww architecture and combine them into a single daemon.

Once the plugins model has been added to both the record and user layer, there's not really any need for the split architecture. The default API would be a records only API, essentially what the politeiad API is now. There would be an --enableusers flag that would enable basic user functionality; enable the basic user routes and layer user permissions onto the record routes. Adding functionality beyond the basic record and user functionality would be done via plugins.

[lukebp]

politeiad/api/v1/mime needs to be deprecated. Accepted MIME types should be a politeiad config option.

politeiad/api/identity doesn't belong there either.

[lukebp]

I've been thinking about a better way to display the proposal home page now that we have comprehensive proposal statuses. I was thinking about three tabs:

Under Review - proposals being discussed and proposals being voted on.
Active - proposals that have been approved and are being actively billed against.
Ended - all proposals not in the first two tabs.

The user would have the ability to apply filtering criteria to these lists. They could filter by proposal status as well as some or all of the proposal metadata (category, dates, budget).

If you come across any projects with a good UX for this kind of thing, feel free to share them. Listed below are some of the other governance websites in this space.

https://vote.makerdao.com/polling
https://grants.zfnd.org/proposals

[lukebp]

Can we use the same key format as matrix so that matrix and politeia keys are cross compatible?

[amass01]

Nice one!

[xaur]

Matrix E2EE uses a bunch of key pairs for different purposes but for the most part it seems to be Ed25519 and Curve25519. More in this guide.

I'm not sure if Matrix E2EE has a "master key" though. In Politeia it is trivial to export public+private key pair. In Matrix the only thing I can export (Element: Settings > Security) is the "key bundle". This is an ever-growing file since new keys are constantly generated, about 0.5 MB/year or more, depending on your usage of encrypted rooms.

If the newer "cross-signing" system (introduced to simplify device verification UX) is widely adopted, perhaps one of the keys used in it could serve as the "master key" we could aim to be compatible with. The spec suggests it also uses Ed25519.

[lukebp]

Considerations when adding a Docker image.

decred/dcrd#2740
decred/dcrd#2735

[lukebp]

The politeiad identity changed between the git backend and the tlog backend, which highlight an issue with the current architecture. All of the receipts that have been saved to disk can no longer be verified without manually looking up the git backend public key and hardcoding it somwhere. Since the politeiad public key is never saved to disk anywhere, it's even possible for a sysadmin to lose it, at which point all of the receipts are useless.

A better way to do this would be to turn the politeiad signatures into a plugin. It would have a public key journal that tracks the server's public key history. The API would allow the politeiad backend or other plugins to request receipts for data blobs as well as lookup what the server public key was at a specific unix time. It would be able to support multiple key types.

[lukebp]

We probably need a records identity plugin to handle the server identity and then a user identity plugin to handle the user identities.

[xaur]

Curious why "politeiad public key is never saved to disk anywhere", isn't it public knowledge?

[lukebp]

It's public knowledge until the sysadmin updates the key, then there's no source of truth for what the previous keys were.

[xaur]

Oh now I see the importance of this feature. Does "public key journal" mean a branch/thread of tlog or a separate structure?

[lukebp]

Haven't fully thought it through yet, but most likely a tlog tree that contains just the key history.