MatrixAI / Polykey

Polykey Core Library - Open Source Decentralized Secret Sharing System for Zero Trust Delegation of Authority
https://polykey.com
GNU General Public License v3.0
29 stars 4 forks source link

NodeId to Fort/Castle Icon Generation Ala CryptoKitties or CryptoForts NFTs #698

Open CMCDragonkai opened 2 months ago

CMCDragonkai commented 2 months ago

Requirements of this design

  1. NodeIds can be visually represented with a fort/castle icon.
  2. This can be done using the 32 byte public key as the "DNA"
  3. Creating these visual icons requires a pattern map as well as compositional elements to be put together
  4. Visual material design is copyrighted by Matrix AI obviously
  5. This can make it easier to identify Polykey nodes, and gives a sense of "uniqueness" and ownership of individual Polykey nodes within any given Gestalt. In fact, a gestalt can be represented by a "visual territory" like a map of castle/forts in a game world. And thus abstract graph of a gestalt could be visualised as territory in virtual space. In fact it is, simply by the fact it is also claiming digital identities - and subsequently other digital artifacts.
  6. The DNA algorithm that maps the 32 byte sequence to the composition should be simple at first, and enable layering by re-using partitioned bit-space. Then the protocol of the composition can be published, while not necessarily immutable.
  7. The actual artifacts themselves should not be pictures that are hosted in a third party system. We want avoid the NFT poop problem. They should just be deterministically generated with a protocol algorithm.
  8. The final "look" of the rendered pixels or rendered ascii can be copyrighted though!

Additional context

How does a 32 byte sequence actually lead to the DNA controlling the composition? I explored this with chatgpt: https://chat.openai.com/share/e/09ff0fa2-e6ed-472b-b89a-71161b9a4e3e.

Designing a castle icon generator with 256 bits from an Ed25519 key doesn't necessarily mean you need 256 distinct visual elements, with each bit directly flipping an element on or off. A more nuanced approach can be used to create a diverse range of castles without needing such a large number of individual elements. Here's a more intelligent way to design the system: ### Efficient Use of Bits 1. **Group Bits for Attributes**: Instead of using each bit for a separate element, group bits to represent different attributes of a castle. For example, a group of several bits could determine the castle's size, another group for the color scheme, another for the style (medieval, fantasy, gothic, etc.), and so on. 2. **Attribute Complexity**: Some attributes could use more bits (allowing for greater variation), while others might need fewer bits. For example, color might need fewer bits than architectural style. ### Types of Visual Elements 1. **Structural Elements**: These include the basic shape of the castle, towers, walls, gatehouses, etc. Different combinations of these elements can create a wide variety of castle silhouettes. 2. **Textural Elements**: Different textures can be applied to the castle's surface, like stone, brick, or wood finishes. 3. **Color Schemes**: Have a range of color palettes that can be applied to different parts of the castle. 4. **Decorative Elements**: Flags, banners, crests, statues, and other decorative details can add uniqueness to each castle. 5. **Environmental Settings**: The surrounding environment can also be varied – like having the castle on a hill, beside a river, in a forest, etc. ### Example Bit Allocation - **Structural Elements (60 bits)**: Various combinations for the structure of the castle. - **Textural Elements (40 bits)**: Different textures for the walls and towers. - **Color Schemes (40 bits)**: Selection of colors for different parts of the castle. - **Decorative Elements (60 bits)**: Variety in decorative details. - **Environmental Settings (56 bits)**: Different landscapes and backgrounds. ### Artistic Considerations - **Cohesion**: Ensure that all elements are designed to work together harmoniously, regardless of how the bits are combined. - **Scalability**: Elements should be scalable to different resolutions without losing quality. - **Style Consistency**: Maintain a consistent artistic style across all elements to ensure that the final generated image looks cohesive. Using this approach, you can effectively translate the 256-bit key into a rich variety of castles without needing an impractically large number of distinct visual elements. The key is in how you map the bits to the attributes and how creatively you design the elements within each attribute category. --- To explore how groups of bits can represent attributes in a 10-bit space for your castle icon generator, let's break down the concept with an example. The idea is to assign different groups of bits to different attributes, where each group's binary value translates to a specific feature or variation. ### 10-Bit Example Breakdown Suppose we have a 10-bit key: `1011100110`. We can divide these 10 bits into groups, each representing a different attribute of the castle. Let's assume three attributes for simplicity: Size, Style, and Color. 1. **Size (first 3 bits)**: `101` - Represents the size of the castle. 2. **Style (next 4 bits)**: `1100` - Determines the architectural style. 3. **Color (last 3 bits)**: `110` - Decides the color scheme. ### Attribute Mapping 1. **Size** (3 bits = 8 possibilities): - `000`: Very small - `001`: Small - `010`: Medium-small - `011`: Medium - `100`: Medium-large - `101`: Large - `110`: Very large - `111`: Enormous 2. **Style** (4 bits = 16 possibilities): - `0000`: Medieval - `0001`: Gothic - `0010`: Renaissance - `0011`: Baroque - `0100`: Victorian - `0101`: Fantasy - `0110`: Steampunk - `0111`: Modern - `1000` to `1111`: Other unique styles 3. **Color** (3 bits = 8 possibilities): - `000`: Gray stone - `001`: Sandstone - `010`: Dark stone - `011`: White marble - `100`: Red brick - `101`: Gold accents - `110`: Blue accents - `111`: Green mossy stone ### Example Castle Generation Using our 10-bit key `1011100110`: 1. **Size**: `101` (Large) 2. **Style**: `1100` (Steampunk) 3. **Color**: `110` (Blue accents) So, this key would generate a large Steampunk-style castle with blue accents. ### Advantages of This Approach - **Efficient Use of Space**: By grouping bits, you can represent a wide range of attributes without needing a 1:1 mapping of bits to features. - **Flexibility**: You can easily adjust the number of bits per attribute based on their importance or the variety you want to offer. - **Scalability**: This method can be scaled up (with more bits) or down (with fewer bits), allowing for different levels of complexity. By using groups of bits to represent various attributes, you create a more manageable and flexible system for generating unique castle icons. This method effectively harnesses the combinatorial power of binary coding to produce a diverse range of outcomes from a limited bit space. --- Yes, you've understood it correctly. Using sequential groups of bits allows you to represent different values (or cardinalities) of an attribute. If you want to add an extra attribute while maintaining the same 10-bit limit, one approach is to indeed create overlap among the bit groups. This method can introduce more complexity and variety without increasing the bit count. ### Overlapping Bit Groups Overlapping bit groups means that the same bits contribute to the determination of more than one attribute. It's a way to use the same bits for multiple purposes, depending on how you interpret them in different contexts. ### Example with an Additional Attribute Let's add an attribute for "Roof Type" to the previous 10-bit example (`1011100110`), with the first 2 bits overlapping with the "Size" attribute. 1. **Size (first 3 bits)**: `101` - Large. 2. **Style (next 4 bits)**: `1100` - Steampunk. 3. **Color (last 3 bits)**: `110` - Blue accents. 4. **Roof Type (overlapping first 2 bits)**: `10` - Gable Roof. ### Attribute Mapping for Roof Type (2 bits = 4 possibilities): - `00`: Flat Roof - `01`: Pointed Roof - `10`: Gable Roof - `11`: Dome Roof ### Considerations - **Complexity in Interpretation**: Overlapping bits mean that the same bits are interpreted in multiple ways, which can add complexity to how you map and understand these bit groups. - **Potential for Reduced Distinctiveness**: Since the same bits are being reused, there's a risk that the variation and uniqueness of the icons might be slightly reduced. - **Careful Design Needed**: This approach requires careful planning to ensure that the overlapping bits don't lead to undesirable combinations or limit the diversity of the generated icons. Using overlapping bit groups is a clever way to add more attributes without increasing the number of bits. However, it requires thoughtful design to ensure that the resulting icons remain diverse and visually appealing. This method is a form of efficient encoding, allowing you to extract more information from a limited bit space. --- Using overlapping bits to add more attributes while maintaining a limited bit space indeed requires careful design. The goal is to maximize variety and avoid reduced distinctiveness. Here's a strategic approach to using overlapping bits effectively: ### 1. Purposeful Overlap Design - **Complementary Attributes**: Choose attributes for overlap that complement or enhance each other. For instance, overlapping bits that determine the "Size" and "Roof Type" of the castle should ideally result in combinations that make sense together. A larger castle size could be more likely to have more elaborate roof types. - **Balanced Impact**: Ensure that the overlapping bits have a balanced impact on each attribute. No single attribute should dominate the influence of these bits. ### 2. Controlled Variability - **Adjusting Cardinality**: If one attribute has many possible values (high cardinality) and another has fewer (low cardinality), the overlap should be designed so the high cardinality doesn't overshadow the low cardinality attribute. This can be managed by how you interpret the bit patterns. - **Attribute Weighting**: Assign different weights or significance levels to the attributes. More critical attributes might have less overlap or more dedicated bits. ### 3. Redundancy and Error Checking - **Redundancy in Design**: Introduce some redundancy in how attributes are determined. This means certain combinations of bit patterns can lead to the same attribute, ensuring that essential characteristics are preserved. - **Error Checking**: Implement checks to avoid undesirable or nonsensical combinations. For example, certain bit patterns might be flagged to prevent unrealistic castle designs. ### 4. Advanced Encoding Techniques - **Non-linear Mapping**: Rather than a direct binary-to-attribute mapping, consider using more complex functions or algorithms to interpret bit patterns, allowing for more sophisticated and less predictable outcomes. - **Contextual Interpretation**: The meaning of overlapping bits could change depending on the context or other bits' states. This dynamic interpretation can increase the diversity of outcomes. ### 5. Iterative Testing and Refinement - **Prototype and Test**: Build prototypes and test how the overlapping bits influence the generated icons. Adjust the bit-grouping strategy based on these outcomes. - **Feedback Loops**: Incorporate user feedback or automated testing to identify patterns that work well or need adjustment. ### Conclusion The key to using overlapping bits effectively is to balance the need for variety and distinctiveness with the limitations of the bit space. Thoughtful design, careful mapping, and continuous testing and refinement are essential. This approach can lead to a richly diverse set of outcomes, making the most of the limited bit space while maintaining the uniqueness and appeal of each generated icon. --- To enhance the variety and uniqueness of your castle icon generator using a limited bit space, employing non-linear mappings, adjusting attribute cardinality, and weighting attributes differently can be highly effective. Let's explore these concepts with examples: ### Non-Linear Mappings 1. **Hash Functions**: Use a hash function to transform your bit groups into a different set of values. Hash functions can take a small input (like a few bits) and produce a more varied output, which can then be mapped to attributes. 2. **Curved Distributions**: Instead of a linear mapping (where each bit combination has an equal chance), use a curved distribution. For example, certain styles or colors might be rarer based on a logarithmic or exponential curve applied to the bit values. 3. **Conditional Logic**: Implement conditional logic where the meaning of a bit group changes depending on another attribute's state. For example, a bit pattern could mean one color scheme if the castle is large, but a different scheme if it's small. ### Adjusting Cardinality 1. **Variable Bit Group Size**: For attributes with more significance or required variety, allocate more bits. For instance, if architectural style is more impactful than color, allocate more bits to style. 2. **Fixed vs. Variable Attributes**: Some attributes could have a fixed set of options (low cardinality), while others could vary more significantly. For example, you might have 4 possible roof types but 16 possible castle sizes. ### Attribute Weighting 1. **Priority Attributes**: Give more weight to attributes that significantly impact the overall appearance. This can be done by allocating more bits or using more complex mappings for these attributes. 2. **Combinatorial Weighting**: Design the bit allocation so that combinations of certain attributes are more or less likely. For example, larger castles could be more likely to have complex roof structures, achieved by overlapping bits for size and roof type. 3. **Frequency Modulation**: Control the frequency of certain attributes appearing. For instance, you might want rare castle styles to only emerge from specific, less common bit patterns. ### Practical Application Let's apply these concepts in a simple scenario using a 10-bit sequence: - **Original Bits**: `1011100110` - **Non-Linear Mapping**: Apply a hash function to transform these bits. - **Attribute Allocation**: Allocate 4 bits to size (allowing for 16 variations), 3 bits to style (8 variations), and 3 bits to color (8 variations), with some overlap. - **Attribute Weighting**: Give more weight to size and style than to color. By using these techniques, you can create a more dynamic and interesting mapping from your bit sequence to the attributes of your castles, enhancing the variety and uniqueness of each generated icon. The key is to find the right balance that maintains diversity without compromising on the distinctiveness and aesthetic appeal of each icon. --- Yes, you are correct. Ed25519 public keys are generated in such a way that their 256-bit representations are uniformly distributed. This means each possible combination of bits is equally likely. However, by applying a curved distribution to these bits, you can indeed create rarity from this uniform randomness. ### Creating Rarity from Uniform Randomness 1. **Curved Distributions**: By using a non-linear, curved distribution, you can assign different probabilities to the occurrence of certain features in your castle icons. This allows some features to be more common and others to be rare, despite the underlying uniform randomness of the key. 2. **Examples of Curved Distributions**: - **Exponential or Logarithmic Curves**: These can be used to make certain attributes more rare. For instance, an exponential curve could mean that certain architectural styles or colors only appear in a very small fraction of the castles. - **Bell Curve (Normal Distribution)**: This could be used to make certain features common and others (at the tails of the curve) rare. For example, most castles could be of average size, with very large or very small castles being uncommon. 3. **Mapping Bit Patterns to Distributions**: You can map the bit patterns from the key to these distributions. For instance, only a specific range of bit patterns might map to the rarest castle feature under an exponential distribution. 4. **Balancing Rarity and Appeal**: It's important to balance the rarity created by these distributions with the overall appeal and diversity of the castle icons. Rare features should be desirable but not overpower the appeal of more common features. ### Impact on Game Dynamics and Player Engagement - **Player Excitement**: Rarity created in this manner can add excitement and a sense of achievement for players who obtain rare castles. - **Trading and Collectibility**: If your game includes trading or collectible aspects, rare castles could become more valuable, enhancing the game's dynamics. By applying curved distributions to the uniform randomness of Ed25519 keys, you can effectively create a sense of rarity and uniqueness in your castle game. This approach adds an interesting layer to the game's dynamics and can enhance player engagement. --- Indeed, the vast number of combinations from a 256-bit pattern can lead to an overwhelming workload for the designer. To manage this, you don't necessarily need unique designs for each bit combination. Instead, you can repeat possibilities and use techniques to manage the complexity effectively. Here's how to approach this: ### Repeating Possibilities for Larger Bit Patterns 1. **Modular Design**: Create a set of modular elements for each attribute. For example, a limited number of castle styles, materials, and colors. The bit pattern selects from these predefined modules. 2. **Combinatorial Variety**: Rather than unique designs for each combination, focus on how different elements combine. The same castle style can look significantly different with varied materials, colors, or defensive features. 3. **Pattern Mapping**: Map multiple bit patterns to the same design element. For instance, several different bit combinations could result in a "stone wall" or "energy shield". ### Simplified Attribute Allocation Consider simplifying the attributes and their bit allocation. For instance: 1. **Style (15 bits)**: Fewer styles but still diverse, like basic futuristic, Chinese, and European. 2. **Size and Material (15 bits)**: Combine size and primary material into one category. 3. **Color Scheme (10 bits)**: A smaller range of color schemes. 4. **Defensive Features (10 bits)**: Fewer but versatile options, such as walls and energy barriers. 5. **Special Features (10 bits)**: Simplified set of unique features for each castle. ### Scaling Complexity - **Use of Rarity**: Apply curved distributions to make certain combinations rare, adding value to them without needing a unique design for each. - **Randomization with Limits**: Allow some level of randomization within controlled parameters, ensuring that the outcomes are still aesthetically pleasing. - **User Customization**: Let players customize certain elements. This reduces the need for excessive pre-designed options and increases player engagement. By using these techniques, you can significantly reduce the workload on the designer while still maintaining a rich variety of castle designs. The key is in the intelligent mapping of bit patterns to a manageable set of well-designed, combinable elements. --- Certainly! Here's a concise plan of attack for your designer to start with. This plan is structured to manage the complexity of designing for a 256-bit key system while ensuring a rich variety of castle icons: ### Phase 1: Foundation Building 1. **Understand the Concept**: Familiarize with the 256-bit key idea and how it translates into visual elements for castle icons. 2. **Define Core Attributes**: Identify key attributes for castles - Style, Size, Material, Color Scheme, Defensive Features, Landscape, Special Features. 3. **Create Basic Elements**: Design a basic set of elements for each attribute. Focus on diversity but keep the number manageable. ### Phase 2: Modular Design Development 1. **Modular Element Creation**: Develop modular design elements for each attribute. For example, 10-15 styles, 5-10 materials, a palette of colors, etc. 2. **Combination Rules**: Establish rules for how these elements can be combined. Ensure compatibility and visual harmony. 3. **Prototype Sample Castles**: Create sample castles using combinations of these elements to test the concept. ### Phase 3: Advanced Design Features 1. **Introduce Overlapping Attributes**: Implement overlapping attributes, like combining Size and Material into one group. 2. **Apply Curved Distributions**: Design rare and common features using curved distributions for attributes like Style and Special Features. 3. **Feedback and Iteration**: Test the designs, gather feedback, and iterate to improve the visual appeal and diversity. ### Phase 4: Finalization and Testing 1. **Refinement**: Refine the designs based on feedback and testing results. 2. **Scale Testing**: Ensure designs scale well across different resolutions and screen sizes. 3. **Finalize Design Library**: Finalize the modular design elements and their combinations. 4. **Documentation**: Document the design elements, their bit mapping, and combination rules for future reference and updates. ### Deliverables - **Design Element Library**: A set of modular design elements for each castle attribute. - **Combination Rulebook**: Guidelines on how elements combine and interact. - **Sample Designs**: A collection of sample castle icons showcasing the variety and scope of designs. This plan provides a structured approach, starting from understanding the concept to creating a diverse set of castle icons, with a focus on manageable workload and iterative improvement. It allows for creativity within a structured framework, essential for handling the complexity of a 256-bit key system.

image

Don't forget that "cryptolinks" the claims posted on identity providers are literally a point of virality. They should be designed as well in relation to the capabilities of IdPs - some are more capable like Github gists, some are less like LinkedIn posts.

Most IdPs have some pictorial capability, but not everything does. Like HN accounts are just pure text. Even with pure text, one could create ASCII style pictures. That could be one way to do it. We can have several different "forms" of cryptolinks suited to a particular IdPs, with a isomorphic mapping function defined between each.

Specification

TBD

  1. ...
  2. ...
  3. ...

Sub-Issues & Sub-PRs created

TBD

  1. ...
  2. ...
  3. ...
linear[bot] commented 2 months ago

ENG-291 Fort/Castle Icon Generator Ala CryptoKitties or CryptoForts

CMCDragonkai commented 2 months ago

@CryptoTotalWar @faithveloro09

CMCDragonkai commented 1 month ago

Also once all the forts are connected into a gestalt territory, we can have some cool visualisations of the "digital territory" controlled by a gestalt.

image

image

image

CMCDragonkai commented 1 month ago

A 2.5D avatar would be cool too.