Admin Dashboard Layout Discussion

[pwdel]

[pwdel]

• I forgot to put a moderation section.
• Comments On/Off
• Market Approval On/Off
• If Market Approval is On, All Submitted (or Edited) Markets Go Into Pending Queue Prior to Being Approved for Public
• If Not Approved, Can Submit Back With Notes to Submitter
• Need to Have Submitted Drafts Inbox for Submitters
• Submitter Can Delete Draft if Never Approved
• Submitter Can Attach Explainer Note if Re-Submitting with Edit
• If Market Approval Off ... Admin Can Still Go In And De-Approve Market, Which N/A's it and Archives It, Masking Title with Explanation. Archived / Unapproved Markets

[pwdel]

• What about...Unresolve Markets? Re-Resolve...?
• Needs to Be a Trail of Re-Resolved Markets with Optional Explinations.

[jg-you]

Other

• Delete users
• Minimal theming (instance name, logo, set currency name)
• Minimal economic control (market creation cost, standard bet sizes.)

Unresolve, re-resolve, etc would all be on the question page itself I think.

[pwdel]

How about:

1. Sandbox Users ... because if a user creates bets, that messes with the history if you, "delete it." Is your concern people creating offensive/toxic user display names? Or not wanting erroneously created users which open up for accidental, non-controlled betting...for example you, create 101 users instead of 100 and the last one somehow gets emailed to someone twice, allowing them to double bet?
2. Theming is no problem.
3. Economic Controls: What needs to be part of a dashboard, meaning it gets changed on the fly, vs. what needs to be set at the start of the game and not changed?

Currently everything is configurable at the start of the game/server and all calculations depend upon these constants.

https://github.com/openpredictionmarkets/socialpredict/blob/main/backend/setup/setup.yaml

Another question...what about exporting data (apart from backups)?

One would think you would want to be able to export all markets with a button, bets, users at any time so you have a record in .csv format?

What about a, "Halt Game," ... "Halt Betting" "Halt Market Creation" button(s) for the end of a tournament/semester? Perhaps Halt Game would halt everything, whereas the other two options would halt the requisite items. E.g. sometimes stock markets have trading holidays?

Backups...I see this as a different problem than exporting data. I think there needs to be backups of the database on a regular basis in case something happens, e.g. if the game is lost, it can be recovered. Backups should just be a given and ideally there should be an optional plugin to S3. Whereas exports I see more as, "it's in CSV format, for ease of research and data analytics usage."

There's CSV, or a flatfile with json, whatever format that could be exports whereas backups would be a dump file compatible with postgres.

[pwdel]

We had a couple of questions come in about what the, "Send Bailout," and "Change Debt Limit" features are, or just more clarity around those.

• The idea behind, "Send bailout," comes from the use of SocialPredict as teaching a tool in a forecasting class. This anticipates the eventuality that a few students might just completely blow up their accounts in the first few weeks.

• SocialPreidct overall would cache as little as possible in the entire platform to minimize the usage of databases (e.g. make it as stateless as possible) - except one's balance. This was after discussions with Andreas Zwinkau, who is the guy who implemented this while he was a phyics PhD student: https://github.com/qznc/prema

• So basically, "Send bailout," would be a way to up an individual users' cached, "wallet," - intended for the instance in which they blow up their account. In the interests of transparency, there would need to be a /stats page which records and publicizes this transaction, showing which accounts received bailouts and what the exact transaction date was for that bailout. Optionally an administrator could never send a bailout...but my thought is, it would be better to publicize sent bailouts rather than the alternative, which would be to create a new shadow account, or multiple shadow accounts. It's like being able to say, "OK, well this person A still wants to play, let's send them a bailout...boom there's the record of the transaction," ... as opposed to, secretly letting them have another account.

• This user's profit calculation would still be consistent, so basically you could calculate profitability over time and a bailout payment would not be entered into the profitability ledger (though obviously if they were not bailed out they would not have been able to continue to make profit).

• The other form of bailout which was proposed is, "change individual debt limit," ... Which is a form of, "bailing everyone out." So basically, let's say you had a small number of users, e.g. 2/30 who sucked up all of the profit and everyone's cached wallet balance is low...well, you could just give everyone the ability to borrow way more points and start over again. So if you initially started a tournament out giving everyone the ability to borrow 500 points (which is similar to Manifold giving everyone 500 free credits at the start, but with a 0% interest rate), you could later change this to 1000 points to bail everyone out, thereby injecting cash into the economy. Obviously this is going to cause inflation. But again, my thought was that this could all be reported on the stats/ page, if we have a consistent way of calculating inflation over time.

[pwdel]

Started forum style discussion. https://github.com/orgs/openpredictionmarkets/discussions/321

[pwdel]

Over time, the notion of creating a more robust user model has come up, with the concept perhaps of creating MODERATOR type user accounts rather than just ADMIN.

MODERATORS may have different tiers, there could be an ECONOMIC_MODERATOR and a USER_MODERATOR.

The USER_MODERATOR could be responsible for content and user conduct, e.g. preventing or flagging toxic content. The ECONOMIC_MODERATOR could have more to do with actual economic decision making, such as raising the debt level or sending bailouts, which might be considered much more drastic, non-every-day decisions.

Whereas the ADMIN user type might be a more secure level, that is really in charge of adding users and setting permissions, fundamental application level stuff. Hypothetically there should only be one ADMIN level account and its access should be very secure, and it controls all other user types, including the USER_MODERATOR and ECONOMIC_MODERATOR, however it doesn't have the powers of the moderators, to keep a separation of concerns.

There might be also a, MARKET_MAKER user type which is not a MODERATOR but is designed to play the functions of a traditional market maker, e.g. take positions in exchange for liquidity. Hypothetically the ECONOMIC_MODERATOR can send continual bailouts to the MARKET_MAKER which would be one way of increasing the supply of points into the system beyond just changing the debt level.

If the application were designed this way, then bailouts paid to the MARKET_MAKER could be more transparent and be reported on the /Stats page.