PhD chapter?: Long-enduring Leaderless Circular Economy (MicroDAOs)

[InvictusRMC]

Public Brainstorming Issue

[InvictusRMC]

Minimal Viable DAO

• Effective Altruism
• Kidney donation noble prize
• Circular economy;
  • Resource donation --> reward
  • Rewards can be social badges or cold hard bitcoin
• Goodness mining idea:
  • Matching donors with resource donators

-->

• Superior scalability
• No need for full view of donors and contributors; only requires partial knowledge.
• Meticulously avoids central banks

-->

DAOs:

• Metadata DAO
• Seedbox DAO

[synctext]

MeritRank incremental deployment

Nobody has ever realised a robust decentralised trust framework. After trying since 2006 (discussions pre-date the existance of Github, see 2013 discussion) we have the MeritRank algorithm for reputation and trust. We need to deploy this, make it feature complete, and use it for "Justin Bieber is Gay" tag spam.

Limited protocol evolution is unsolved. Our network is forked for each new feature or minor protocol change. That needs to change. We currently do not have a mechanism inside IPv8 for easy and light weight versioning. We really want to avoid complex versioning negotiation between client. Versioning is strictly an increasing integer. Each integer is associated with a certain set of supported immutable message formats. Message deprecation is not supported.

Release planning:

• Tribler 7.13 (July 2023) Rendezvous only.
• Tribler 7.14 (Aug 2023) Randevouz and every peer requests 1 random badge of a new peer. Our crawl obtains a fully connected graph with 25k connected peers.
• Tribler 7.15 (Sep 2023) Even more fancy a month later.
• Tribler 7.16 (Oct 2023) Even more fancy a month later.
• Tribler 7.17 (Nov 2023) Even more fancy a month later. MicroDAOs with robust spam protection and Beta economy
• Tribler 8.0 (Dec 2023) Tribler PRO release :fire: :fireworks: :fire:

Current IPv8 versioning

The IPv8 message Introduction-Request has magic bytes which have never been used, except for a single Vadim experiment. ### EXTRA_BYTES is a string that can be used to piggyback extra information.. Another mechanism, the version field inside the IPv8 protocol header has a hardcoded value, also not used version = b'\x02'.

A third mechanism in included inside the PopularityCommunity. With the overhead of custom messages this implements a VersionRequest and VersionResponse mechanism.

My question to everybody and especially the founder of IPv8 is: what should we do? First, please read the scientific related work on this: RFC 9170 Long-Term Viability of Protocol Extension Mechanisms.

The above will be painful, because we are now deeply integrating phd science with bug-free development :smiley:

[InvictusRMC]

Rendezvous design

Simple straightforward design. Client $A$ sends an introduction payload $m_1$ consisting of its current signed clock value ($t_a$) using it's secret key $sk_a$. Client $B$ accepts the introduction (e.g. v0 blind accept or reasonable timestamp). If accepted, a signed (using $sk_b$) rendezvous payload $m_2$ is sent back to $A$ including the original introduction payload and the current clock value of $B$ ($t_b$). Both clients store this value in a local DB.

Benefits

• Allows for the derivation of several characteristics (e.g. age, connectivity, uptime).
• Prevents attack vectors to a certain degree.

Possible issues

• Connectionless: issue of losing messages.
  • Message $m_1$ lost? --> resend after timeout up to $n$ times with same timestamp. Eventual receipt of $m_1$ stops resending.
  • Message $m_2$ lost? --> same issue as $m_1$ lost, however, introduces DB inconsistencies at $B$. Solution: on subsequent receipt of $m_1$ drop associated DB entry and update accordingly w.r.t. new $t_b$.
• Issue of previous solutions: introduces the ability for a replay attack. Possible v_1 solution: introduce freshness.

[qstokkink]

My question to everybody and especially the founder of IPv8 is: what should we do?

We have easy and lightweight versioning in IPv8. I'll give some examples below of what already exists, based on what I've seen so far ITT (we even already support message deprecation). I consider protocol-level versioning mostly solved. So on that front, rather than make standard 15, I'd advise to use what is already available.

That said, nobody has ever dared to make the boilerplate to bridge the behaviors of two peers that use two different versions: bridging protocols is easy, bridging behavior is extremely difficult. It's probably worth looking at the behavior instead.

Examples of existing solutions

Regarding versioning of communities and peer search/reconnect, I have two examples by @egbertbouman:

1. The following is an example of integer-based versioning in the wild. This example is even more complex as it is also content-centric, i.e., based on info hashes:

https://github.com/Tribler/py-ipv8/blob/master/ipv8/messaging/anonymization/pex.py#L9-L17

PEX_VERSION = 1

class PexCommunity(Community):
    def __init__(self, *args, **kwargs):
        infohash = kwargs.pop('info_hash')
        self.community_id = (int.from_bytes(infohash, 'big') + PEX_VERSION).to_bytes(20, 'big')
        self._prefix = b'\x00' + self.version + self.community_id
        super().__init__(*args, **kwargs)

2. For efficient peer lookups (which is what I interpret "rendezvous" as) we have the DHTCommunity: https://github.com/Tribler/py-ipv8/blob/master/ipv8/dht/discovery.py#L86-L105

    async def connect_peer(self, mid, peer=None):
        # If a peer is provided, we will first try to ping the peer (to see if it's connectable).
        # This could potentially save an expensive DHT lookup.

Regarding the "rendezvous" design above, all (Python) IPv8 users send signed introduction requests that includes an identifier attribute, which is its local timestamp:

https://github.com/Tribler/py-ipv8/blob/master/ipv8/community.py#L218-L225

payload = IntroductionRequestPayload(socket_address,
                                     self.my_estimated_lan,
                                     self.my_estimated_wan,
                                     True,
                                     u"unknown",
                                     global_time,
                                     extra_bytes,
                                     supports_new_style=new_style)

The response to this message, is another signed message that includes the same identifier as in the request. You can store and load this in/from a database if you like.

[InvictusRMC]

Update:

• Timestamps will never work, I should've known 🤯
• New approach:
  • Count pings send on interval:
  • Initial Piggyback on Introduction messages, subsequent through direct payload
  • Design sketch:
  • Payload:
  • --> [publickey_b, interval, counter, timestamp_a, signature_a]
  • <-- [publickey_b, interval, counter, timestamp_a, timestamp_b, signature_b]

[synctext]

overlap with #6519 "phd topic placeholder - identity, reputation, trust, something" (big thesis issue)

Lesson for future phd students, the cycle of including phd student ideas into Tribler started on 1 June 2023 and is expected to run into September (of an unspecified year). PR: https://github.com/Tribler/tribler/pull/7517

[synctext]

Cardinal challenge: Creating a trustworthy Web3 economy without gatekeepers. This requires the emergence of trust based upon interactions between cooperating agents with resilience against misreporting, slander, cheaters, Sybil attacks, and centralisation. Gatekeepers often grow into central bottlenecks within digital economy, furthermore they need to give explicit permission for each disruptive innovation. The services of such gatekeepers are often vital. Thus the role of the gatekeeper remains, but it is transformed into a decentralised shape.

background In 1970 is was nearly impossible to start an international movement as an individual. This changed. Fifty years ago it used to be much more necessary to be part of an organization to work on ambitious projects. It was the only way to get the resources you needed, the only way to have colleagues, and the only way to get distribution. So in 1970 your prestige was in most cases the prestige of the organization you belonged to. And prestige was an accurate predictor, because if you weren't part of an organization, you weren't likely to achieve much.