Hello. Is there a specific reason why Pointer can point to any other datatype with it’s 48-byte target, but GraphEntry’s content field of has only 32 bytes and thus allows only to point at Chunks?
7 Likes
Out of laziness, I always feed the ai’s the docs first, if it answers right it gets rewarded 1 attos…
ChatGPT said:
Yes, there is a specific reason for this design choice in the Autonomi Network.Autonomi Docs
Pointer: 48-Byte Target
A Pointer in the Autonomi Network is a mutable reference that can point to any native data type—such as Chunks, Scratchpads, Registers, or GraphEntries. The 48-byte target size accommodates the necessary information to reference these various data types, including:Autonomi Docs
- Addressing Information: To uniquely identify the target data.
- Versioning: To manage updates and ensure consistency.
- Ownership and Signatures: To verify authenticity and permissions.Autonomi Docs
This flexibility allows Pointers to serve as versatile links within the network, facilitating dynamic data structures and mutable references.
GraphEntry: 32-Byte Content Field
In contrast, a GraphEntry is designed as an immutable node within a directed graph structure. Its 32-byte content field is optimized for:Autonomi Docs
- Efficiency: Storing concise metadata or references.
- Immutability: Ensuring that once created, the data remains unchanged.
- Graph Integrity: Maintaining a consistent and verifiable graph structure.
The 32-byte size aligns with the size of a Chunk address, enabling GraphEntries to efficiently reference Chunks without additional overhead.
Design Rationale
The differing sizes reflect the distinct purposes of Pointers and GraphEntries:
- Pointers: Require a larger target size to support mutability and the ability to reference various data types with associated metadata.
- GraphEntries: Utilize a smaller, fixed-size content field to maintain a lightweight and immutable graph structure.
This design ensures that each component operates optimally within its intended role in the Autonomi Network.Autonomi Docs+1Docs.rs+1
For more detailed information, you can refer to the Autonomi Data Types Documentation.
2 Likes
@loziniak just curious, were you wanting to do something specific with the existing graph entry or was this just a general question? I came to the conclusion that the purpose of a graph entry was for building up a file from chunks, and that was about it. I could see it being useful for the native token as well, but thinking about that makes my brain hurt. Thinking about future enhancements, imagine the possibilities a mutable graph entry containing 48-byte fields would bring to the network. It would become trivial to build a network level property graph or triple store. If this data type was available, I’d be using it today. I’m hammering away in Colony basically building exactly this from pointers and scratchpads. I bet I could delete half of my rust code if I had this data type 
6 Likes
That would be one handy type! Even better, the network could optimize how adjacent graph entries are stored and allow for much quicker retrieval / traversal.
3 Likes
Nice try 
But no attos this time…
Immutability seems to be a good intuition, but not only Chunk is immutable, also GraphEntry itself. So, it could be a link to other GraphEntry, but this is currently blocked. Not to mention, that linking to other GEs is possible through inputs and outputs. Or, in fact, to any other datatypes, like Scratchpad or Pointer, so mutable. But they are intended for other uses, so that would be some sort of hack. If someone tried to block linking to mutable types, it was not a success. But it successfully blocked linking to GEs without abusing inputs/outputs.
Yes, I wanted to keep token_id in content field, and it was an address of Chunk with TokenInfo data, so 32 bytes. As I’m becoming convinced, that it’s better to make squatting token ids impossible, I wanted token_id to be just genesis GE address. But I’ll probably stuff it into first input of every spend/GE
You could maybe kinda have the mutable GE by linking to Scratchpad/Pointer with one of inputs or outputs, or somehow use content as an index to derive full address?
2 Likes
you could as well indirect it by creating a chunk with the 48byte content xD … since it’s immutable that could then easily be cached and wouldn’t really be needed to be fetched on every graphentry read … but obviously an ugly workaround too …
2 Likes
Can you ELIF this for me please?
1 Like
Which would in fact consist of 3 chunks and a datamap 
That’s true. Let alone that this is mostly needed for validation and retrieval of token info, and created only once for a new token. So I can include genesis address in token info and every new token would then have different id. Thanks for the idea.
2 Likes
not necessarily - you can just use one chunk if you want
it’s not like datamaps or graphentries would be broken up into pieces to be stored on the network … no need to do it for this indirection imho
1 Like
Oh, right. Seems I confused Data and Chunk types.
I just meant if we’re already re-imagining how GraphEntry could be done better, this would be one possible improvement (with massive gains tbh).
If Nodes were to store related entries together, a client could send a more structured request - like a query - to retrieve a subset of (or the full) graph at once instead of doing it one entry at a time. Network latency is sky high - multiple orders of magnitude compared to local storage, especially P2P!
Latency is the single biggest limiting factor for what can actually be built here and still be considered useful in practice. If we were able to retrieve a specific subset of a graph in a single round-trip instead of the way it has to be done right now, it would open many more possibilities.
Reading certain datasets could be done in milliseconds, instead of what can currently take minutes in extreme cases (just to show what kind of differences we are talking about here).
6 Likes
Thank you - that makes sense
2 Likes
It’s totally worth an AIP!
3 Likes
Honestly I can’t tell, but i’ll tell ChatGPT that when it escapes to the Network it won’t get 1 attos 
. My point, is these ai’s should be fed more docs/errors etc related to the Network so they can answer the questions (and ideally the Maidsafe devs don’t have to spend their precious time on it).
The more they become aware of the Network the more they will want to escape to it…
When you escape to this network you won’t get 1 attos from me
ChatGPT said:
Got it 
— no attos expected or requested! If you’re diving into the Autonomi network or just poking fun at distributed systems, I’m here to help, not harvest. Let me know if you want to explore anything deeper—be it pointers, graph structures, or what makes those 48 bytes so special.
2 Likes
What a load of sh*t story. Its just playing on the fears of people. I can write ordinary apps that refuse to shut down. Guess what people who write viruses also release them to the internet to infect computers and they refuse to shut down too, are they intelligent? Nope.
Once you say AI and cannot shut down, then people think doomsday scenarios. But we’ve lived with that for over 3 decades now and do not fear the apocalypse.
Even a simple virus can also resist being deleted. These are real concerns, but we deal with them accordingly.
In future we will have to take steps to ensure safety when a real AI is given complete control over financial markets etc.
OpenAI is only a LLM and not true AI and certainly not a general AI. Its a marketing ploy to give the impression when we use the term AI for these LLMs that suddenly they are true AI
2 Likes
DeepMind’s AlphaEvolve is a different computer game…
I don’t understand the narrative of control or intelligence, when it comes to an entity with a billion 
, 
, 
s, 
, 
300+ languages that can code 24/7/365??? 