Dev - Revision history

Slackjore: /* Payment channels */ added BIoT example

2019-02-23T12:10:30Z

‎Payment channels: added BIoT example

Slackjore: updated name

2019-01-21T18:26:53Z

updated name

Slackjore: added note re rebranding migration

2019-01-21T16:31:06Z

added note re rebranding migration

Slackjore: updated name

2019-01-20T17:31:13Z

updated name

Punqtured: 17 revisions imported

2019-01-19T22:19:58Z

17 revisions imported

obytewiki_>Tarmo888: missing features

2018-06-06T11:17:56Z

missing features

Slackjore: adjusted markup

2018-06-05T20:46:07Z

adjusted markup

Slackjore: undo

2018-06-05T20:40:32Z

undo

Slackjore: typo

2018-06-05T20:36:43Z

typo

Slackjore: tarmo888 rewrote New section

2018-06-05T20:34:45Z

tarmo888 rewrote New section

@@ Line 205: / Line 205: @@
 ==Payment channels==
 Slack post by tonych [2018-04-01 4:22 PM]: Here is how payment channels can be implemented in BB: https://docs.google.com/document/d/19s4LYDfbWDREzVzUwxPuoKANeIGOgPGKV2zI9jTsPSg/edit#
 ==References==

@@ Line 27: / Line 27: @@
 '''TESTNET'''<br />
-There are commands in `testnetify.sh` file, which need to be run after `npm install` to edit some values in byteballcore library. It will make the bot to communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.obyte.org/. Also, TESTNET wallet at https://byteball.org/testnet.html is also not up-to-date with all the features (single-address wallets & private profile requests) that default MAINNET wallet (https://obyte.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.byteball.org without worrying that you mess something up.
+There are commands in `testnetify.sh` file, which need to be run after `npm install` to edit some values in byteballcore library. It will make the bot to communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.obyte.org/. Also, TESTNET wallet at https://obyte.org/testnet.html is also not up-to-date with all the features (single-address wallets & private profile requests) that default MAINNET wallet (https://obyte.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.obyte.org without worrying that you mess something up.
 == Obyte-to-TCP Proxy ==
@@ Line 34: / Line 34: @@
 This software makes it no longer necessary for the Obyte chatbots to be developed in Node.js. Thus, the developer is free to choose whichever programming language they prefer for the bot. What is more, ''bb2tcp'' can be configured to send notifications to a custom server upon any pairing attempts. The latter can be used to implement two-factor or passwordless authentication (for example, see [http://sndd.io Slice&Dice Dungeon] ).
-To implement passwordless authentication with the help of Obyte, the application should present the user with a customly generated QR code. The payload of that QR code should contain a pairing link such as ''obyte:A/SCXz5tNuJDLuCO8PXpsfUoL7dCMBGnvSST7z0YPXjd@byteball.org/bb#'''bki433fsb''''' where the end part (in bold) is randomly generated by the server. When the user scans the given QR code with their Obyte device a pairing attempt with the code ''bki433fsb'' is made and the ''bb2tcp'' chatbot notifies the application by sending the device address and the provided pairing code to the application server. The application server then knows which Obyte device is attempting to authorize themselves so the respective user session's privileges could be elevated immediately without any input from the user.
+To implement passwordless authentication with the help of Obyte, the application should present the user with a customly generated QR code. The payload of that QR code should contain a pairing link such as ''obyte:A/SCXz5tNuJDLuCO8PXpsfUoL7dCMBGnvSST7z0YPXjd@obyte.org/bb#'''bki433fsb''''' where the end part (in bold) is randomly generated by the server. When the user scans the given QR code with their Obyte device a pairing attempt with the code ''bki433fsb'' is made and the ''bb2tcp'' chatbot notifies the application by sending the device address and the provided pairing code to the application server. The application server then knows which Obyte device is attempting to authorize themselves so the respective user session's privileges could be elevated immediately without any input from the user.
 The ''bb2tcp'' chatbot is developed and maintained by ''@hyena'' from the [https://obyte.slack.com Obyte's official Slack]. All questions and ideas for enhancements are welcome.

← Older revision		Revision as of 16:31, 21 January 2019
Line 1:		Line 1:
	This page is for [[Main_Page\|Obyte]] developer use. It is not dumbed down at all for non-techies.		This page is for [[Main_Page\|Obyte]] developer use. It is not dumbed down at all for non-techies.
		+
		+	For Github repos:
		+	*byteballcore -> ocore
		+	*headless-byteball -> headless-obyte

	==New bot developers==		==New bot developers==

@@ Line 1: / Line 1: @@
-This page is for [[Main_Page|Byteball]] developer use. It is not dumbed down at all for non-techies.
+This page is for [[Main_Page|Obyte]] developer use. It is not dumbed down at all for non-techies.
 ==New bot developers==
-If you know next to nothing about Byteball, then download/install a regular '''light''' client like a normal person would, and get familiar with some existing [[chatbot|bots]] in the Bot Store (Chat > Bot Store). The '''full''' client may take a few days to sync up. Same thing goes for the headless wallet (see below) - you can start developing faster if you run the bot also in light mode (by setting conf.bLight value to true).
+If you know next to nothing about Obyte, then download/install a regular '''light''' client like a normal person would, and get familiar with some existing [[chatbot|bots]] in the Bot Store (Chat > Bot Store). The '''full''' client may take a few days to sync up. Same thing goes for the headless wallet (see below) - you can start developing faster if you run the bot also in light mode (by setting conf.bLight value to true).
 To look into how bots are written, see the Github tutorials at https://github.com/byteball/byteballcore/wiki/Writing-chatbots-for-Byteball.
 '''Getting your hands dirty'''<br />
-What might help most to understand how bots work is to try to get an existing bot working on your machine, such as https://github.com/byteball/email-attestation. If you are able to get that bot running, you can try get any other bot running that can be found on Byteball Github account https://github.com/byteball and after that you are probably ready to start developing your own bot by following the Developer Guides Wiki: https://github.com/byteball/byteballcore/wiki/Byteball-Developer-Guides
+What might help most to understand how bots work is to try to get an existing bot working on your machine, such as https://github.com/byteball/email-attestation. If you are able to get that bot running, you can try get any other bot running that can be found on Obyte Github account https://github.com/byteball and after that you are probably ready to start developing your own bot by following the Developer Guides Wiki: https://github.com/byteball/byteballcore/wiki/Byteball-Developer-Guides
 '''Headless wallet'''<br />
-A headless wallet is like a normal wallet, but without user interface, intended for software code interaction with the Byteball DAG.
+A headless wallet is like a normal wallet, but without user interface, intended for software code interaction with the Obyte DAG.
 More about headless wallet:
@@ Line 23: / Line 23: @@
 '''TESTNET'''<br />
-There are commands in `testnetify.sh` file, which need to be run after `npm install` to edit some values in byteballcore library. It will make the bot to communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.byteball.org/. Also, TESTNET wallet at https://byteball.org/testnet.html is also not up-to-date with all the features (single-address wallets & private profile requests) that default MAINNET wallet (https://byteball.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.byteball.org without worrying that you mess something up.
+There are commands in `testnetify.sh` file, which need to be run after `npm install` to edit some values in byteballcore library. It will make the bot to communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.obyte.org/. Also, TESTNET wallet at https://byteball.org/testnet.html is also not up-to-date with all the features (single-address wallets & private profile requests) that default MAINNET wallet (https://obyte.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.byteball.org without worrying that you mess something up.
-== Byteball-to-TCP Proxy ==
+== Obyte-to-TCP Proxy ==
-With the help of this special [[chatbot]] it is possible to develop the actual bot in any programming language. Byteball-to-TCP Proxy ([https://github.com/heathmont/bb2tcp bb2tcp]) listens on the Byteball network like a regular chatbot, except that for each paired device it establishes a new TCP connection to a predefined server. Thus, it acts as a proxy between a custom TCP server and the paired Byteball client device.
+With the help of this special [[chatbot]] it is possible to develop the actual bot in any programming language. Obyte-to-TCP Proxy ([https://github.com/heathmont/bb2tcp bb2tcp]) listens on the Obyte network like a regular chatbot, except that for each paired device it establishes a new TCP connection to a predefined server. Thus, it acts as a proxy between a custom TCP server and the paired Obyte client device.
-This software makes it no longer necessary for the Byteball chatbots to be developed in Node.js. Thus, the developer is free to choose whichever programming language they prefer for the bot. What is more, ''bb2tcp'' can be configured to send notifications to a custom server upon any pairing attempts. The latter can be used to implement two-factor or passwordless authentication (for example, see [http://sndd.io Slice&Dice Dungeon] ).
+This software makes it no longer necessary for the Obyte chatbots to be developed in Node.js. Thus, the developer is free to choose whichever programming language they prefer for the bot. What is more, ''bb2tcp'' can be configured to send notifications to a custom server upon any pairing attempts. The latter can be used to implement two-factor or passwordless authentication (for example, see [http://sndd.io Slice&Dice Dungeon] ).
-To implement passwordless authentication with the help of Byteball, the application should present the user with a customly generated QR code. The payload of that QR code should contain a pairing link such as ''byteball:A/SCXz5tNuJDLuCO8PXpsfUoL7dCMBGnvSST7z0YPXjd@byteball.org/bb#'''bki433fsb''''' where the end part (in bold) is randomly generated by the server. When the user scans the given QR code with their Byteball device a pairing attempt with the code ''bki433fsb'' is made and the ''bb2tcp'' chatbot notifies the application by sending the device address and the provided pairing code to the application server. The application server then knows which Byteball device is attempting to authorize themselves so the respective user session's privileges could be elevated immediately without any input from the user.
+To implement passwordless authentication with the help of Obyte, the application should present the user with a customly generated QR code. The payload of that QR code should contain a pairing link such as ''obyte:A/SCXz5tNuJDLuCO8PXpsfUoL7dCMBGnvSST7z0YPXjd@byteball.org/bb#'''bki433fsb''''' where the end part (in bold) is randomly generated by the server. When the user scans the given QR code with their Obyte device a pairing attempt with the code ''bki433fsb'' is made and the ''bb2tcp'' chatbot notifies the application by sending the device address and the provided pairing code to the application server. The application server then knows which Obyte device is attempting to authorize themselves so the respective user session's privileges could be elevated immediately without any input from the user.
-The ''bb2tcp'' chatbot is developed and maintained by ''@hyena'' from the [https://byteball.slack.com Byteball's official Slack]. All questions and ideas for enhancements are welcome.
+The ''bb2tcp'' chatbot is developed and maintained by ''@hyena'' from the [https://obyte.slack.com Obyte's official Slack]. All questions and ideas for enhancements are welcome.
-== Byteball address validation in C++ ==
+== Obyte address validation in C++ ==
 <pre>
 <syntaxhighlight lang="cpp">
@@ Line 141: / Line 141: @@
 </pre>
-byteball github repo<ref>https://github.com/byteball/byteball</ref>
+Obyte github repo<ref>https://github.com/byteball/byteball</ref>
 ==Consensus==
@@ Line 147: / Line 147: @@
 A Slack #tech conversation 28/29 March 2018.
-:'''angrytree''' [10:25 PM]: posted in #general, want to see if anyone from byteball can clarify - question about double spending - if a user violates the rule that requires all his txns to have partial order, what's to stop him? do we just go back to the non serial case? for example, if i introduced a pair of conflicting double spending txns, would one be accepted eventually as stated in 4.2? or would both be discarded? if it's the former case, what's the point of introducing the partial order requirement then? looks like witness is used to help with resolving double spending anyway. looks to me, the arbitrary rule of requiring partial order of one's own txns could make byteball prone to censorship attack
+:'''angrytree''' [10:25 PM]: posted in #general, want to see if anyone from [Obyte] can clarify - question about double spending - if a user violates the rule that requires all his txns to have partial order, what's to stop him? do we just go back to the non serial case? for example, if i introduced a pair of conflicting double spending txns, would one be accepted eventually as stated in 4.2? or would both be discarded? if it's the former case, what's the point of introducing the partial order requirement then? looks like witness is used to help with resolving double spending anyway. looks to me, the arbitrary rule of requiring partial order of one's own txns could make [Obyte] prone to censorship attack
 ::'''Punqtured''' [10:44 PM]: @angrytree Is what you're trying to learn, whether the platform will be prone to censorship from witnesses? If so, you're right. The witnesses should therefore be entities with "real world value" at stake. If they misbehave, they will not only be rejected as witnesses, but also lose reputation and credibility in the real world. Think of companies that can't accept to be linked to dubious behavior. That's probably the best explanation I can give about the witnesses. The network relies on witnesses and therefore, in theory, they could collude and censor the platform. It would require the majority of witnesses to collude, for it to be effective, though. When witnesses gets decentralized (this is an issue as of yet) it would be unlikely that 6 different companies with 6 different interests would agree to have their name and reputation spoiled by colluding. The witnesses are covered in the presentation from slide 28
@@ Line 155: / Line 155: @@
 ::'''Punqtured''' [11:01 PM]: Why would referencing your own txns be faster than referencing any others'? (edited)
-:'''angrytree''' [11:13 PM]: borrowing bitcoin's example, may not be applicable to byteball - the txns verification takes time + i don't want my competitors to know the most up to date information. Here in Byteball, seems like only witnesses earn bytes from verifying txns anyway? So I don't see an incentive for normal users to help each other, other than altruism. but what i'm really interested about is just the dag consensus part - partial ordering and double spending
+:'''angrytree''' [11:13 PM]: borrowing bitcoin's example, may not be applicable to [Obyte] - the txns verification takes time + i don't want my competitors to know the most up to date information. Here in [Obyte], seems like only witnesses earn bytes from verifying txns anyway? So I don't see an incentive for normal users to help each other, other than altruism. but what i'm really interested about is just the dag consensus part - partial ordering and double spending
 :::'''HHugh''' [11:22 PM]: From what I understand the fee is split into to categories: header fee and payload fee. Payload fee (about 40% for simple transfers) is equal to the size in bytes of the message; header fee (about 60%) is the balance of the data size. The witnesses collect the payload fee and the header fee goes to whichever user who posts the next child transaction. So a financial incentive exists (however small) to link to childless parent units. Check out pg 17 #13 of the whitepaper for details.

@@ Line 17: / Line 17: @@
 '''Sending payments'''<br />
-Look how existing bots that send payments:
+Look how existing bots send payments:
 *https://github.com/byteball/byteball-faucet
 *https://github.com/byteball/email-attestation/blob/master/modules/reward.js
@@ Line 23: / Line 23: @@
 '''TESTNET'''<br />
-There is sometimes `testnetify.sh` file include in repository, which makes the bot communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.byteball.org/. Also, TESTNET wallet at https://byteball.org/testnet.html is also not up-to-date with all the features that default MAINNET wallet (https://byteball.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.byteball.org without worrying that you mess something up.
+There are commands in `testnetify.sh` file, which need to be run after `npm install` to edit some values in byteballcore library. It will make the bot to communicate with testnet hub, but important thing is to remember that you need to delete your bots existing databases when you already ran the bot on default MAINNET DAG: https://explorer.byteball.org/. Also, TESTNET wallet at https://byteball.org/testnet.html is also not up-to-date with all the features (single-address wallets & private profile requests) that default MAINNET wallet (https://byteball.org/#download) has, so it might be more complicated to develop some features with that wallet app, but the good thing is that you can ask bytes from faucet and write into TESTNET DAG at https://testnetexplorer.byteball.org without worrying that you mess something up.
 == Byteball-to-TCP Proxy ==

← Older revision	Revision as of 22:19, 19 January 2019
(No difference)