Why would it be a tx then? You’re talking about appendable data of unlimited size - right? Or is it a immutable chunk?
I see you wanted an additional data type that doesn’t need to be called tx
Okay - allowing larger content fields is possible - reducing in legacy data not really…
Maybe starting out simple and via pointers does make a lot of sense and if people don’t stop moaning about it and the resolution doesn’t get fast enough to not be a pain we can adapt txs later on… You’re probably right =D
3 Likes
Not really appendable, rather just like transaction – “chainable”. I like this design.
Transactions should remain free, and I understand now the serious limit of content size – we could abuse this by producing thousands of spam transactions to store any size of data even if the limit is small, like couple kB.
2 Likes
Just to be clear, these may incur some tiny costs, but if at network level we use one of these as native currency then it would be an exception and free
2 Likes
This is not a simplification for me 
This would mean creating a native transaction for creating a non-native transaction. Add to that additional code needed to differentiate between two types of txs…
What is the rationale behind making it paid?
not at all, no need for that.
Every tx chain from genesis is different.
spam mainly
2 Likes
Good point. Shouldn’t there be more inputs, than one? Otherwise the amounts become always more divided, do I understand well?
Edit: My question is based on Bitcoin transactions, where there can be multiple inputs, so if we have 2 addresses with 0,3 BTC and 0,7 BTC, we can send someone 1,0 BTC by consolidating these 2 smaller entites.
Edit 2: Ok, this is answered in the Transaction code 
pub struct Transaction {
[...]
pub parents: Vec<PublicKey>,
[...]
}
2 Likes
I remember you were once talking about everyone being able to create his own currency and they all would be equal, and even compete with Native Token. I think we’re losing it here…
I cannot imagine it otherwise. How would you pay for creating a non-native tx then?
Sure. I was talking about the code, that needs to check if transaction is native or not and treat it differently.
Like transaction spam? Or creating too many currencies? Are we afraid of all world’s DeFi moving to Autonomi? 
3 Likes
I don’t think that was ever said tbh. [EDIT What I mean is a native Nework one could be different, but if any all of us create one these would be equal etc.]
I don’t understand. If we pay for tx then we all pay the same?
Ah I see, yes that’s true
yes
no
no 
3 Likes
Replying here without reading 41 subsequent replies after your scratchpad proposal!
That probably works, but…
That’s a narrow use case: a single author website, many of which will not have a problem due to infrequent updating. It would still be worth doing and solves the issue for occasional and more frequently updated single author sites.
There are though many other important use cases that I’ve not even bothered thinking about yet, which this may or may not handle, IDK.
We have never really got onto multi author content with SN APIs and it was always questionable to me how that would work with previous APIs.
I think now might be a good time to be figuring out if and how the API does or could support those, such as blog comments, a forum, public and private messaging etc.
When Transactions are in I will probably start simple and could implement the Scratchpad later (it had occurred to me the Vault might handle this in the way you describe, but maybe this is just terminology? I’ve yet to look at Vault.)
1 Like
Having read the intervening debate I’m not going to beat my head against that wall again.
Also, it’s off topic.
I’m way behind this thread, but just wanted to comment on this.
The more I think about API features, the more it feels like defining language features. Variables, linked lists, etc.
In this context, don’t we really want to lean on types, containing expected values, rather than loosely typed and containing anything?
It feels like data should be stored in chunks. That’s the architecture of the system. It should be very efficient at that and if it isn’t, aren’t there bigger questions to ask here?
I don’t mind the idea of a string meta data field, if we think that is useful (sounds like it could be), but I’d avoid misusing loose types. Losing that uniform behaviour, having to do more validation every time, etc, is probably best avoided.
3 Likes
It feels like some existing open source sites should be studied and/or proof of concepts should be written for these. Specifically, by the folks doing the API design.
The challenges should then be obvious, which with help to determine the solution.
While those of us who have played with client apps may have experienced some of this, it can be hard to articulate the challenges.
1 Like
I agree, but my feeling is start as small as possible and cover initial use cases as we are all doing here. so keep types tight as possible and ring the hell out of them.
For multi user web site owners here we can handle it in a few way, e.g.
- BLS allows multisig, so ensure up front (out of band) agreement on changes
- Transactions allow forking, so concurrent changes can be accommodated, but then the website authors need to agree which fork to follow
Just as examples. I am not stating actual hard and fast designs here, but some examples.
I feel it’s a bit like Vint and IP or TBL and http or even google etc. We don’t really know where or how this will go, but if we start very tight and simple as possible we can let growth happen normally. I also feel true decentralised will mean we open many doors not previously visible. Things like everyone having their own site or commenting system that links to others in some way, so not centralised or owner owned or fully open centralised data types, but whole new designs.
I am not articulating well as usual, but the key for me is have an API that is
- simple
- honest
- tight
To start with and then really push at it and I think so far the community have pushed at it, but not had the support or focus from the team. I see that now needs to change and I know it will, bigly
7 Likes
Does it somehow help us that bls allows for 1 of n signatures? Or requires the derivation process all n participants?
It can do both, so it allows us to be a bit more creative with our designs. My only fear of BLS though is if we have to switch to a quantum secure sig scheme then none of them have this feature. so we could code ourselves into a corner.
It’s an issue I have with some things where we tweak and use everything available in a module and get so tied in that it becomes an issue to change it, but apart form that we can do 1 of n, n of n, derivation of sigs and also encryption. So there is a lot of things available to us here in BLS alone. I don’t feel many have exploited that just yet and I don’t know why.
[EDIT What I mean above is things I have seen in the past like serialisation as an example, where we can tweak every bit of performance from a lib, or compression etc. and then some new much better more secure alternative exists (even when the lib we use becomes totally insecure, so a must change) and we cannot move cause we are so tied in with complex and custom tweaks. Then all changes are met with “OMG that’s a total rewrite”]
6 Likes
Well… As of now I’m not afraid of someone being able to finance a quantum pc trying to crack my personal signatures… So I see your point but think we could deal with quantum security when it’s time for that and for now can enjoy the nice sides of bls and try to get this network out the door +make it successful with every trick we can utilise …?
And I think with (publicly readable) scratchpad, immutable chunks and txs, together with bls (multisig and n of m sig) I think I would have everything I need to program the use cases I’m currently looking at… Even in a performant way if the network returns data somewhat performant 
… Scratchpad would mainly be used to support and make the combination of the other 2 more performant…
3 Likes
I am in the same boat there actually. If the whole finance sectors about to fail I suspect we will have plenty notice 
3 Likes
Pretty simple. An address/32 bytes on its own does not describe what the 32 bytes is for, an address, a value, a ???
So if a second 32 byte value is allowed then it can provide an address to the meta data along with the link
And then 2 x 4 bytes (or other suitable small number of bytes) for a flag to say what the 1st 32 bytes is for and what the 2nd 32 bytes is for.
72 bytes total. Not storing the data but links to the data. eg addresses of contents file and meta data file/chunk with flags allowing the app to know what the 2 x 32 byte values are for
4 Likes
This is a key part.
So there can be trillions of these Transaction (types). All app defined. So the app already know what the 32 bits is.
OK, that’s not the whole story I reckon.
So you have an app or a use case where you use the 32 bytes for a value or a pointer. Your app does not need flags or whatever to know what that is, unless your appp needs additional stuff in there, but again like a c pointer should we extend the pointer to have another ‘type’ field.
There’'s a strong argument to say, hell no. But there is also another argument to say, this could be a universal type identifier that other apps could use the same transaction chain for.
The rest of additional fields etc. feels like nice to have and for devs it’s always nice to have more, why not 10 extra etc.
And this is the key part we need to get to . I think we have to ask,
- Are we staring with the most simple solution first
Or
- Are we trying to cover all future use cases before we design such use cases.
And this is the part I feel that we need to be careful of and I repeat again want to build apps personally, I want companies to build apps and I want that to be easy. If we take any type in any programming language there is always a desire to have it do more than the basic functionality. So again I ask, are we staring with the most basic functionality here or do we want a picking list of stuff we might use (any might misuse).
This is the crux of the point I am hoping to make here. Are we offering the most simple start.
4 Likes