New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP 808 - ERC for a Standard Decentralized Booking Protocol #808

Open
wants to merge 16 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@appyhour770

appyhour770 commented Dec 26, 2017

EIP 808 - ERC for a Standard Decentralized Booking Protocol

appyhour770 added some commits Dec 26, 2017

@pirapira pirapira added the ERC label Jan 2, 2018

@pirapira

This comment has been minimized.

Member

pirapira commented Jan 2, 2018

Please use the number 808 instead of 770. (The convention is to use the issue number or a PR number in this repository, and #770 is already a PR about something else).

I'll review this today or tomorrow.

## Abstract
The following describes standard functions for a decentralized booking protocol that can be used to reserve any kind of resource (Hotel, concert ticket, restaurant table).

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

Hotel-->hotel room?

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Yes, hotel room

Category : ERC
Status: Draft
Created: 2017-12-26
Requires : ERC 20

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

An extra space before :.

Requires: 20
should be fine.

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Will be done in next submission

(Step 6.2 - Optional) Provider cancels the reservation by broadcasting a cancellation request. This triggers a submission to the RES smart contract that empties the registries for this resource. RES smart contract is releasing the escrowed amount to booker.
(Step 7.1 & 7.2) Booker is notifying that the resource has been paid (presumably at resource check-out). RES smart contract is releasing the escrowed BTU back to user in addition to a BTU agreed commision.

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

Spelling: commision should be commission.

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

To be fixed in next submission

## Motivation
The Booking Token Unit (BTU) protocol is a building block for any decentralized application (dApp) or web site willing to implement booking features for their end-users.

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

Is the name of the protocol

  • The Booking Token Unit protocol, or
  • Decentralized Booking Protocol?

If these two are different protocols, where is the Booking Token Unit protocol described?

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

There is only one protocol, the "Booking Token Unit protocol" that is the subject of this ERC

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

The title reads differently.

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Title was not meant to name the protocol, but thanks for this valuable feedback, I adjusting the title accordingly

The Booking Token Unit (BTU) protocol is a building block for any decentralized application (dApp) or web site willing to implement booking features for their end-users.
This standard also brings interoperability among decentralized applications that incorporate it.
We strongly believe that a transparent and public inventory enabled by an open-source standardized protocol would considerably lower the entry barriers to many Internet booking markets.

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

An extra space after a.

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Will be fixed in next submission

The BTU protocol involves potentially ten steps and our standardized decentralized reservation contract (RES). Some of following steps can be relayed off-chain, but are always settled on-chain.
<img src="./eip-770/protocol-steps.png">

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

The image contains an Ethereum logo. Ethereum logos are distributed under Creative Commons Attribution 3.0. Please follow the term of the license.

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Thanks for this reminder that will be taken into account in next submission

<img src="./eip-770/protocol-steps.png">
Hereafter the general sequence :

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

An extra space before :.

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Will be fixed in next submission

(Step 7.1 & 7.2) Booker is notifying that the resource has been paid (presumably at resource check-out). RES smart contract is releasing the escrowed BTU back to user in addition to a BTU agreed commision.
## Implementation

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

The implementation section is supposed to contain links to testable code.

BookingStatus _bookingStatus ; // reservation status
string _metaDataLink // Link to Meta Data of the bookable resource (desc, image links, etc…)
}
//Submit one or multiple availability - implementation will be off-chain

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

Why does an offchain functionality appear in the interface of an Ethereum contract?

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

We did this for pedagogical reasons (easier to understand).
Also, because sample implementation may implement on-chain functions (for testing without scalability)

}
//Submit one or multiple availability - implementation will be off-chain
function publishAvailabilities (address _owner, availability[] _availability, bytes32 signatureProof ) constant returns (uint status);
//Query Availabilities - implementation will be off-chain

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

Why does an offchain functionality appear in the interface of an Ethereum contract?

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

We did this for pedagogical reasons (easier to understand).
Also, because sample implementation may implement on-chain functions (for testing without scalability)

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

If an implementation has this function on-chain, is the implementation still compliant to this ERC?

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Yes. Because the ERC specified "eventually" off-chain (not mandatory to be off-chain)

string _metaDataLink // Link to Meta Data of the bookable resource (desc, image links, etc…)
}
//Submit one or multiple availability - implementation will be off-chain
function publishAvailabilities (address _owner, availability[] _availability, bytes32 signatureProof ) constant returns (uint status);

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

A _ seems to be missing in front of signatureProof.

This comment has been minimized.

@appyhour770
//Request reservation
function requestReservation(address _requester, availability _availability) constant returns (uint status);
//Check booking status
function getReservationStatus(address _requester, availability _availability) constant returns (BookingStatus status);

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

Why is status sometimes BookingStatus and sometimes uint?

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Thanks for this relevent remark. The correct type is BookingStatus and this mistake came from a bad copy and paste (from a previous code base)

```
contract ERC770 is ERC20 {

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

Why does this need to be an ERC20?

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Because during the process (step 3.1 or6.1 for instance), the allowance & approve may be called by the RES smart contract

This comment has been minimized.

@pirapira

pirapira Jan 2, 2018

Member

The RES contract doesn't need to be an ERC20 contract for calling allowance or approve. The callee needs to be ERC20, but the caller doesn't need to.

This comment has been minimized.

@appyhour770

appyhour770 Jan 2, 2018

Sorry for my quick reply.
You are right, RES smart contract does not have to be ERC20, however in the sample implementation we are doing it (but not required). Still, the BTU tokens have to ERC20 compliant.
I realize that my description can this code sample is confusion and that it's more clear to separate the token from the RES contract.
This (valuable) feedback will be taken into account in next submission to make things more clear.

@pirapira

The use of the Ethereum logo should follow the terms of the license on which it's distributed.

A specification of the on-chain component is desired.

@pirapira

This comment has been minimized.

Member

pirapira commented Jan 2, 2018

Also, GPL 3.0 is not common in this repository. I'm asking other editors what they think.

appyhour770 added some commits Jan 2, 2018

Update schema
Update schema
Adjusting licence
Adjusting licence
@appyhour770

This comment has been minimized.

appyhour770 commented Jan 5, 2018

Following your comments, i've submitted new files. Waiting for a new (and final) review

@appyhour770

This comment has been minimized.

appyhour770 commented Jan 5, 2018

Following your comments, I've submitted new files for (final) review.

@pirapira

This comment has been minimized.

Member

pirapira commented Jan 24, 2018

Why does the PNG image say "Ethereum or other platforms"? Is the standard meant for other platforms as well?

appyhour770 added some commits Feb 4, 2018

Update eip-808.md
Fix typo
@appyhour770

This comment has been minimized.

appyhour770 commented Feb 4, 2018

"Ethereum or other platforms" was referencing, for instance, a private Ethereum network.
For more clarity and since the protocol makes more sense on the public network, this mention has been removed to simply "Ethereum"

@pirapira

This comment has been minimized.

Member

pirapira commented Feb 8, 2018

@appyhour770 let's just say "Ethereum" because this is an Ethereum Improvement Proposal.

@appyhour770

This comment has been minimized.

appyhour770 commented Feb 11, 2018

"let's just say Ethereum because this is an Ethereum Improvement Proposal"
Agree and PNG updated

@Arachnid

This comment has been minimized.

Collaborator

Arachnid commented Mar 27, 2018

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

  • Frontmatter is now contained between lines with only a triple dash ('---')
  • Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---
New EIPs format + Link to reference Implementation
New EIPs format + Link to reference Implementation
@berreb

This comment has been minimized.

berreb commented May 18, 2018

@appyhour770 sauf erreur, tu dois écrire:
type: Standards Track
au lieu de
type: Standard

;)

@@ -98,7 +98,7 @@ contract RES {
uint _minDeposit ; // minimum BTU deposit for booking this resource
uint _commission ; // commission amount paid to booker in BTU
uint _freeCancelDateTs; // Limit date for a reservation cancellation
uint _statDateTs; //availability start date timestamps
uint _startDateTs; //availability start date timestamps
uint _endDateTs; //availability end date timestamps
BookingStatus _bookingStatus ; // reservation status
string _metaDataLink // Link to Meta Data of the bookable resource (desc, image links, etc…)

This comment has been minimized.

@tomsoft1

tomsoft1 Sep 10, 2018

Should add a semicolumn add the end of _metaDataLink ?

@appyhour770 appyhour770 changed the title from EIP 770 - ERC for a Standard Decentralized Booking Protocol to EIP 808 - ERC for a Standard Decentralized Booking Protocol Nov 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment