(N1) --E1--> (N2) ---E2---> (N3)
^ |
|-----E3-----|
Whoa, edges are also objects (meaning nodes/vertices)?
Can you give me an example of why that is necessary or would be useful?
So if I have:
(N1) --E1--> (N2) ---E2---> (N3)
^ |
|-----E3-----|
First is this an acceptable "graph" in BitShares? And who "owns" edge 3? The source "node" of edge 3 is edge 2. The source node of edge 2 is node 2. So does that mean that the owners of N2 control edges 2 and 3?
And edge cannot be a source Vertex only a destination vertex.
And edge cannot be a source Vertex only a destination vertex.
Well right now an edge can be a source, shall we change it?
And edge cannot be a source Vertex only a destination vertex.
Well right now an edge can be a source, shall we change it?
You could make validation non-Constant time Because you may have to look back source source source source owner.
It's not necessary and maybe not useful, but we're not going to add complexity to remove a feature =)
And edge cannot be a source Vertex only a destination vertex.
This means that you can construct an edge from a node to an edge or from an edge to an edge.
Is this the last big addition to the protocol before 1.0? Looks really interesting and it will be great if we can advertise that we have a better data structure than ethereum.
It's not necessary and maybe not useful, but we're not going to add complexity to remove a feature =)
So it seems like the primitives in the BitShares Object Graph are node and edge objects which are very similar to one another (both can have arbitrary JSON associated) with the following important differences:
- The edge object needs a source object (perhaps only restricted to node objects, TBD) and a destination object while the node object does not have those things.
- The node object has an ACL (multisig owners and multisig updaters) defined on it while the edge object does not. These permissions are the source that propagate the ACL to the edges spreading out from the node.
And edge cannot be a source Vertex only a destination vertex.
If that is the case, you should fix the following statement in your blog post.QuoteThis means that you can construct an edge from a node to an edge or from an edge to an edge.
http://bytemaster.bitshares.org/article/2014/12/24/Introducing-BitShares-Object-Graph/
The primitive is only "object". Edges are not any more special than other "special" objects like accounts, assets, auctions, sites, etc - they just have some extra validation.
The primitive is only "object". Edges are not any more special than other "special" objects like accounts, assets, auctions, sites, etc - they just have some extra validation.
Looking through the code I see there is a clear distinction between an actual edge (in the graph sense) implemented with bts::blockchain::edge_record type, which has from and to fields, and the concept of the edge_object discussed in this thread and in bytemaster's blog post, implemented with the bts::blockchain:object_record type, which has the actual data and the _owners field or a pointer to use the _owners of another object (which I presume points to the source node of the "edge").
My question is if in the original graph example I gave in this thread the E1 "edge" would be represented as object_record with obj_type == edge_object and two edge_records (one from N1 to E1 and the other from E1 to N2), or would there be a single edge_record going from N1 to N2 that somehow gets associated with an object_record with obj_type == edge_object.
If it is the former, can we just use regular graph terminology and call the "edges" in the BitShares Object Graph special vertices (perhaps named edge_objects). In which case, the actual edges (in graph terminology) would have no information associated with them other than the from and to fields (no weights for example). It would also not make any sense to have these edges go directly from a vertex where obj_type != edge_object to a vertex where obj_type != edge_object. The edge_objects would be special from all other vertices in the graph in the sense that they have particular validation semantics and can only have one outgoing edge (assuming you guys decide to not allow an "edge" be the source of an "edge" as bytemaster suggested because of the non-constant time validation consequence).
Or you know, stop trying to make edges point to other edges (unless there is a good reason for this feature), and build the graph database the traditional way...
E1 "edge" would be represented as object_record with obj_type == edge_object and two edge_records (one from N1 to E1 and the other from E1 to N2), or would there be a single edge_record going from N1 to N2 that somehow gets associated with an object_record with obj_type == edge_object.
lol, I recall mentioning graph DB here some time ago. Good work danYes charles maybe everything you wanted in a coin was right here all along :)
lol, I recall mentioning graph DB here some time ago. Good work danYes charles maybe everything you wanted in a coin was right here all along :)
http://bytemaster.bitshares.org/article/2014/12/24/Introducing-BitShares-Object-Graph/+5% This is excellent and of bigger importance than most people realize.
This is the most confusing exciting news I've heard all week.
Better than ethereum is enough for me.
+5%
groundbreaking and thought provoking! +5%
u mistyped primtive btw.
Ethereum stuck to primitives or assembly.. And a double directed graph would cut down dev costs and ease of use on primitives.. however the million dollar question is: Is there a case you can think of where you would not want to use a graph but use primitives to solve a problem?
I guess vitalik assumes others will build on top if there is a market todo so while we give a leg up on beginners to solve problems quicker but if its a subset of problems then there is a case for primitives or assembly still. That is when will flexibility of primitives be needed in this context where a graph wouldnt work for a layman?
groundbreaking and thought provoking! +5%
u mistyped primtive btw.
Ethereum stuck to primitives or assembly.. And a double directed graph would cut down dev costs and ease of use on primitives.. however the million dollar question is: Is there a case you can think of where you would not want to use a graph but use primitives to solve a problem?
I guess vitalik assumes others will build on top if there is a market todo so while we give a leg up on beginners to solve problems quicker but if its a subset of problems then there is a case for primitives or assembly still. That is when will flexibility of primitives be needed in this context where a graph wouldnt work for a layman?
It's also possible that Vitalik simply over looked this. Building something like Ethereum is hard but I think if you're going to build a scripting language you need to make it high level. Right now they have scripting but as a person who can read several programming languages their scripting is awkward and low level.
I think now that they have the resources the Ethereum team should make a scripting language as much like Python or Javascript as possible. You want something which has minimal syntax for people to learn and which is powerful enough to do the job. Python is good as a scripting language because it's powerful but the syntax is very simple.
Serpent is supposed to be like Python and it's getting closer but it's not quite there. I think the competition between Bitshares and Ethereum should be on making it easy to develop for. Whichever DAC is easier to develop for will certainly win over my attention and I would think most people who aren't rock star developers at the same way.
C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.
groundbreaking and thought provoking! +5%
u mistyped primtive btw.
Ethereum stuck to primitives or assembly.. And a double directed graph would cut down dev costs and ease of use on primitives.. however the million dollar question is: Is there a case you can think of where you would not want to use a graph but use primitives to solve a problem?
I guess vitalik assumes others will build on top if there is a market todo so while we give a leg up on beginners to solve problems quicker but if its a subset of problems then there is a case for primitives or assembly still. That is when will flexibility of primitives be needed in this context where a graph wouldnt work for a layman?
It's also possible that Vitalik simply over looked this. Building something like Ethereum is hard but I think if you're going to build a scripting language you need to make it high level. Right now they have scripting but as a person who can read several programming languages their scripting is awkward and low level.
I think now that they have the resources the Ethereum team should make a scripting language as much like Python or Javascript as possible. You want something which has minimal syntax for people to learn and which is powerful enough to do the job. Python is good as a scripting language because it's powerful but the syntax is very simple.
Serpent is supposed to be like Python and it's getting closer but it's not quite there. I think the competition between Bitshares and Ethereum should be on making it easy to develop for. Whichever DAC is easier to develop for will certainly win over my attention and I would think most people who aren't rock star developers at the same way.
C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.
They have serpent and solidity working and full IDEs in development. We will not beat them as a smart contract platform unless we outgrow them first. More likely we will just pull in their VM once both of our systems are more mature.
We are basically all-in on BitAsset adoption and very basic financial services.
C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.CoffeeScript is even easier. It is basically 1 for 1 with JavaScript and gets rid of most of the unnecessary work.
I gotta learn that oneC++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.CoffeeScript is even easier. It is basically 1 for 1 with JavaScript and gets rid of most of the unnecessary work.
C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.CoffeeScript is even easier. It is basically 1 for 1 with JavaScript and gets rid of most of the unnecessary work.
http://bytemaster.bitshares.org/article/2014/12/24/Introducing-BitShares-Object-Graph/+5% This is excellent and of bigger importance than most people realize.
groundbreaking and thought provoking! +5%
u mistyped primtive btw.
Ethereum stuck to primitives or assembly.. And a double directed graph would cut down dev costs and ease of use on primitives.. however the million dollar question is: Is there a case you can think of where you would not want to use a graph but use primitives to solve a problem?
I guess vitalik assumes others will build on top if there is a market todo so while we give a leg up on beginners to solve problems quicker but if its a subset of problems then there is a case for primitives or assembly still. That is when will flexibility of primitives be needed in this context where a graph wouldnt work for a layman?
It's also possible that Vitalik simply over looked this. Building something like Ethereum is hard but I think if you're going to build a scripting language you need to make it high level. Right now they have scripting but as a person who can read several programming languages their scripting is awkward and low level.
I think now that they have the resources the Ethereum team should make a scripting language as much like Python or Javascript as possible. You want something which has minimal syntax for people to learn and which is powerful enough to do the job. Python is good as a scripting language because it's powerful but the syntax is very simple.
Serpent is supposed to be like Python and it's getting closer but it's not quite there. I think the competition between Bitshares and Ethereum should be on making it easy to develop for. Whichever DAC is easier to develop for will certainly win over my attention and I would think most people who aren't rock star developers at the same way.
C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.
They have serpent and solidity working and full IDEs in development. We will not beat them as a smart contract platform unless we outgrow them first. More likely we will just pull in their VM once both of our systems are more mature.
We are basically all-in on BitAsset adoption and very basic financial services.
If we are all-in on bitassets then shouldn't our priority be to get the protocol stable so we can launch 1.0 and have no further hard forks a for a long time? Only then will we be able to get gateways, our biggest priority.
We already have the killer app, but it's super difficult to get hold of because gateways don't want to integrate with us because our system is still unstable. I think we should have just focused on getting the last UIA changes implemented, and then only focus on UX for the next 6 months for the amazing products we already have. We don't need scripting in the short term, there's not any evidence in the market that it's actually profitable or useful, only hype.
I dont think we should be beginning on working on even more complicated stuff now if it doesn't actually give us any marketing advantage over ethereum. It makes no sense from a business perspective. We need to get our product ready, and then launch it.
+5%groundbreaking and thought provoking! +5%
u mistyped primtive btw.
Ethereum stuck to primitives or assembly.. And a double directed graph would cut down dev costs and ease of use on primitives.. however the million dollar question is: Is there a case you can think of where you would not want to use a graph but use primitives to solve a problem?
I guess vitalik assumes others will build on top if there is a market todo so while we give a leg up on beginners to solve problems quicker but if its a subset of problems then there is a case for primitives or assembly still. That is when will flexibility of primitives be needed in this context where a graph wouldnt work for a layman?
It's also possible that Vitalik simply over looked this. Building something like Ethereum is hard but I think if you're going to build a scripting language you need to make it high level. Right now they have scripting but as a person who can read several programming languages their scripting is awkward and low level.
I think now that they have the resources the Ethereum team should make a scripting language as much like Python or Javascript as possible. You want something which has minimal syntax for people to learn and which is powerful enough to do the job. Python is good as a scripting language because it's powerful but the syntax is very simple.
Serpent is supposed to be like Python and it's getting closer but it's not quite there. I think the competition between Bitshares and Ethereum should be on making it easy to develop for. Whichever DAC is easier to develop for will certainly win over my attention and I would think most people who aren't rock star developers at the same way.
C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.
They have serpent and solidity working and full IDEs in development. We will not beat them as a smart contract platform unless we outgrow them first. More likely we will just pull in their VM once both of our systems are more mature.
We are basically all-in on BitAsset adoption and very basic financial services.
If we are all-in on bitassets then shouldn't our priority be to get the protocol stable so we can launch 1.0 and have no further hard forks a for a long time? Only then will we be able to get gateways, our biggest priority.
We already have the killer app, but it's super difficult to get hold of because gateways don't want to integrate with us because our system is still unstable. I think we should have just focused on getting the last UIA changes implemented, and then only focus on UX for the next 6 months for the amazing products we already have. We don't need scripting in the short term, there's not any evidence in the market that it's actually profitable or useful, only hype.
I dont think we should be beginning on working on even more complicated stuff now if it doesn't actually give us any marketing advantage over ethereum. It makes no sense from a business perspective. We need to get our product ready, and then launch it.
brag is much more easy than doing.
New year is coming.
where is pts, bts and dns? where is the new wallet.
where is vote, music, play?
Don't make any promise before you have done it...
There is no brag. PTS/DNS were killed by official i3 support.
Some people like discussion before it is implemented. If you do not feel you can come up with something worth adding to the discussion then excercise your option of listening and not just opening your mouth?
I assume this is one of the final pieces before we have the final 1.0 protocol. Am i right?
http://bytemaster.bitshares.org/article/2014/12/24/Introducing-BitShares-Object-Graph/
I think we just went to Crypto 3.0. :)
Some questions:
Would the data be stored on the blockchain? Wouldn't that lead to blockchain bloat? Take the example of a Forum of linked Posts: Would all posts be stored on the blockchain? Or is it that only the identities, trust levels of identities would be stored on chain?
Since domain names and voting seem to be being built based on the bitshares graph database, would it make sense to say that the BitShares DAC consists of three parts: BitAssets, UIA, graph database applications?
What i wanted to say was these were the last few changes to the protocol before 1.0I assume this is one of the final pieces before we have the final 1.0 protocol. Am i right?
Scripting wasn't planned to be implemented in 1.0. This is also just the data structure and wont actually mean that scripting will be functional according to toast. Dont understand why its being put on the testnet but maybe only some of the devs are working on finishing off 1.0 while others are already working on the future updates. I guess that is a good sign meaning that 1.0 will be here relatively soon, probably end of jan.
groundbreaking and thought provoking! +5%
u mistyped primtive btw.
Ethereum stuck to primitives or assembly.. And a double directed graph would cut down dev costs and ease of use on primitives.. however the million dollar question is: Is there a case you can think of where you would not want to use a graph but use primitives to solve a problem?
I guess vitalik assumes others will build on top if there is a market todo so while we give a leg up on beginners to solve problems quicker but if its a subset of problems then there is a case for primitives or assembly still. That is when will flexibility of primitives be needed in this context where a graph wouldnt work for a layman?
It's also possible that Vitalik simply over looked this. Building something like Ethereum is hard but I think if you're going to build a scripting language you need to make it high level. Right now they have scripting but as a person who can read several programming languages their scripting is awkward and low level.
I think now that they have the resources the Ethereum team should make a scripting language as much like Python or Javascript as possible. You want something which has minimal syntax for people to learn and which is powerful enough to do the job. Python is good as a scripting language because it's powerful but the syntax is very simple.
Serpent is supposed to be like Python and it's getting closer but it's not quite there. I think the competition between Bitshares and Ethereum should be on making it easy to develop for. Whichever DAC is easier to develop for will certainly win over my attention and I would think most people who aren't rock star developers at the same way.
C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.
They have serpent and solidity working and full IDEs in development. We will not beat them as a smart contract platform unless we outgrow them first. More likely we will just pull in their VM once both of our systems are more mature.
We are basically all-in on BitAsset adoption and very basic financial services.
If we are all-in on bitassets then shouldn't our priority be to get the protocol stable so we can launch 1.0 and have no further hard forks a for a long time? Only then will we be able to get gateways, our biggest priority.
We already have the killer app, but it's super difficult to get hold of because gateways don't want to integrate with us because our system is still unstable. I think we should have just focused on getting the last UIA changes implemented, and then only focus on UX for the next 6 months for the amazing products we already have. We don't need scripting in the short term, there's not any evidence in the market that it's actually profitable or useful, only hype.
I dont think we should be beginning on working on even more complicated stuff now if it doesn't actually give us any marketing advantage over ethereum. It makes no sense from a business perspective. We need to get our product ready, and then launch it.
What i wanted to say was these were the last few changes to the protocol before 1.0I assume this is one of the final pieces before we have the final 1.0 protocol. Am i right?
Scripting wasn't planned to be implemented in 1.0. This is also just the data structure and wont actually mean that scripting will be functional according to toast. Dont understand why its being put on the testnet but maybe only some of the devs are working on finishing off 1.0 while others are already working on the future updates. I guess that is a good sign meaning that 1.0 will be here relatively soon, probably end of jan.
because either Bitcoin prices will be flat, will go lower, or will go into another epic bubble.
Ok, thanks. And do market pegged and user issued assets also make use of / build on this graph database? Or is it only VOTE and DNS that make use of it?Some questions:
Would the data be stored on the blockchain? Wouldn't that lead to blockchain bloat? Take the example of a Forum of linked Posts: Would all posts be stored on the blockchain? Or is it that only the identities, trust levels of identities would be stored on chain?
Since domain names and voting seem to be being built based on the bitshares graph database, would it make sense to say that the BitShares DAC consists of three parts: BitAssets, UIA, graph database applications?
The blockchain size does not matter. Transaction fees will prioritize use. Yes all data is in blockchain so it can be referenced by future scripts.
because either Bitcoin prices will be flat, will go lower, or will go into another epic bubble.
Lol how else can price react ? : )))
It is Public domain
It is Public domain
Cheers!
Posted here (https://bitcointalk.org/index.php?topic=905616.0).