Hashtag QP: A transparent decentralised software-agnostic version of Quantified Prestige

I had the recent realization that it would be possible to test Quantified Prestige in reality very easily even without writing a single line of code! The trick is to use the web as a whole as public database and interface!

Note: You should have read the basics of the Quantified Prestige System Documentation V0.03 quantifiedprestige003.pdf (334.6 KB) or later.

Hashtag Quantified Prestige

The core idea is to use hashtag codes written anywhere in the web where they can be seen publicly for esteem Quantification Point (QP) allocation. Sidenote: I’ve just overloaded the QP abbreviation, but that’s cool. So, it’s a totally transparent version of QP, but that’s perhaps not so bad in order to test out a simple version of the system and to gain some public attention for it.

Hashtag Codes

How do the QP hashtag codes look like? The general form is:

#QP[ Network]: [Sender] [Signal] [Recipient] [@Timestamp] ["Message"]

The square brackets are optional and only should be used, if Sender or Recipient contain any numbers. Note that in this forum hashtags need to be escaped by backslashes like “\#”, so that they aren’t interpreted as markdown for headings.

  1. Network: This is the QPN for which the code applies. If no network is mentioned, it is assumed that it’s the general global Hashtag QP Network (HQPN). For the start, we will ignore the possibility of multiple networks, but it may be a useful feature for the future.
  2. Sender: The Sender needs to use a handle to declare herself to the system. In theory, this is optional, since the sender is usually clear from the context (every person can only allocate her own QPs to others), but if that person has multiple online handles, having an explicit QP handle makes things a lot easier. Also, writing down the sender explicitly makes it easier to crawl the internet for codes written by a certain person.
  3. Signal: This species an allocation of QPs. Simple signals are of one of the three forms:
  • A: +amount, which increases the amount of QPs allocated from sender to recipient by amount.
  • B: -amount, which decreases the amount of QPs allocated from sender to recipient by amount.
  • C: amount, which sets the amount of QPs allocated from sender to recipient to amount.
    More types of signals might be possible in the future, for example making flux (Fluido) transactions (yeah, madness, I know).
  1. Recipient: The recipient can be any entity than can be referred to by a usual string. For simplicity’s sake, in the first stage of the Hashtag QP system, recipients should be only persons who are easily identified via their names or handles.
  2. Timestamp: This is an optional date that specifies when the code has been written, or should go into effect.#
  3. Message: This is an optional text message from the sender to the recipient attached to the code.

Examples

  • #QP: Radivis +200 zanthia @2016-03-07-22:00GMT+1 “Thank you very much!” – this increases my QPs for zanthia by 200 (if nothing else was written beforehand from previously 0)
  • #QP: Radivis 500 Joao_Luz “Good job!” – this sets my QPs for Joao_Luz to 500
  • #QP: Radivis -50 zanthia @2016-03-07-22:45GMT+1 “That was unfair!” – this decreases my QPs for zanthia by 50 (so that they are at 150 now, if they were at 0 in the beginning)

Guildelines

  • The order of codes is sometimes important, so this system should be used on websites that allow at least a rough dating of the hashtag code, otherwise people would need to trust the timestamp in the code itself.
  • Senders should always be written out, even if that part of the code is optional

General Rules

The rules for the codes depend on the network that is specified in the codes. Here are the rules for the general global Hashtag QP Network (HQPN):

  1. I set all the rules of the HQPN and can change them at any time, until otherwise noted.
  2. Every person has a fixed amount of 12000 QPs.
  3. Malformed codes are discarded.
  4. Once a person has already used up his 12000 free QPs, automatic reallocation, as defined in the documentation, kicks in.

What’s the point of this kind of system?

The point is that this system allows people to use and test the QP system without the need to have any single line of code, without having to register at any site, and without having to use any kind of specific interface other than the hashtag codes. Sure, without any actual code this is a very sketchy system, but the code can be implemented after the system is used. It’s not a requirement that there’s an already existing software in order to use the system! Given that there’s no public implementation of QP yet, this is a significant advantage.

Advantages of Hashtag QP

  • It works without specific QP software!
  • It’s decentralized from the start!
  • It can be used on any web based platform without the need for any integrating software.
  • It’s a very quick and easy way of rewarding others (with QPs)!
  • It’s a very easy way of providing quantified feedback!
  • Hashtag QP codes will probably become (optional) integrated interfaces of software implementation of QP later on, so in a way they are importing real functionalities from the future!
  • Even if there are one day different software implementations of QP, the Hashtag QP codes might still be a universal protocol.

Disadvantages of Hashtag QP

  • It’s not trivial for users to see how much free QPs they still have, how they have been allocating their QPs, and what the current Prestige score of anyone is.
  • It’s all transparent, so private allocation of QPs is pretty much impossible in this system.
  • It’s really a very sketchy system that’s probably not very reliable.
  • It’s probably inferior to serious implementations and integrations of QP, once they exist.

Let’s start?

What do you think about the idea? I guess it will require further clarification, but at least this initial description might allow for some fun quick and dirty experimentation with the QP system. Should we start using it in the F3 already?

1 Like