🎓Fractional usage and calendaring

[micahalcorn]

The eventual goal is to support fractional-use DApps that will involved a calendaring function. Some ideas around this are outlined in the white paper.

Things to Consider

• mapping user-friendly times and smart contracts
• challenges with daylight savings, time zones, etc
• business process requirements
• iCalendar standard
• variable pricing on-chain in an efficient format

To Do

• [x] UI changes supporting time intervals ranging from minutes to year(s)

[nick]

I think schema.org and jsonschema can work well together... schema.org for defining things like field names and structure and jsonschema for doing the actual object validation. We may outgrow react-jsonschema-form but we can still leverage ajv, for example, to do the heavy lifting of validating an object.

Here's an example of a LodgingReservation as JSON-LD:

{
  "@context": "http://schema.org",
  "@type": "LodgingReservation",
  "reservationId": "abc456",
  "reservationStatus": "http://schema.org/ReservationConfirmed",
  "underName": {
    "@type": "Person",
    "name": "John Smith"
  },
  "reservationFor": {
    "@type": "LodgingBusiness",
    "name": "Hilton San Francisco Union Square",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "333 O'Farrell St",
      "addressLocality": "San Francisco",
      "addressRegion": "CA",
      "postalCode": "94102",
      "addressCountry": "US"
    },
    "telephone": "415-771-1400"
  },
  "checkinTime": "2017-04-11T16:00:00-08:00",
  "checkoutTime": "2017-04-13T11:00:00-08:00"
}

[tyleryasaka]

@wanderingstan Agreed - super interesting problems we get to tackle!

Yeah right now there's not a lot to look at - just a bunch of edits to the smart contracts in that branch. Soon I'll have actual smart contracts and unit tests for fractional listings - that should be more interesting to look at.

[tyleryasaka]

Opened a pull request for v1 of fractional usage contracts: https://github.com/OriginProtocol/origin-js/pull/251

[lucadgtrip]

I’m adding my perspective as a Dapp marketplace project in the Homesharing space.

INSTANT BOOKING: NOT NEEDED NOW The Instant Booking feature wouldn’t even be used by Hosts at the beginning. Origin Dapps will start as a minor booking provider for them. If an Host gets 10% of bookings from Origin and 90% from Airbnb, she will fear Airbnb and won’t care too much about Origin, which will be just an experiment. This leads to cancellations (in case of Instant Bookings) or refusals (in case of On Request Bookings). Most Hosts will try Origin out and manually review each booking. We’ve seen this happening over the years with Airbnb and Booking.com competitors such as Wimdu, HouseTrip or Tripadvisor: most Hosts would not opt-in for Instant Bookings or often refuse them when they got one (due to not updated prices for instance). A refused Instant Booking is toxic for the Guests’ experience and the platform. Just imagine booking a place, buy a flight and then get a cancellation: you now need to find another place for the same dates and price. So, I agree with the choice.

Of course if Instant Booking was trivial to develop and could be given as an option, some Hosts would use it, which brings us to another questions: would Guests use it? Probably not. Trust is needed before users feel confident to Instant Book on a platform. Even more so on a blockchain/crypto platform.

Having said that: in the long run it WILL be needed, as it makes the user experience so much better and all OTAs push hard for it. Have you seen “Daddy's Home Two” where Mel Gibson (instant) books a house on Airbnb while the others are fighting over what to do on Xmas? That shows how important they are to Airbnb. Also, Instant Booking carries another message: “price and availability are 100% correct”, which boosts also non Instant Bookings and in general the platform credibility. But, again, it’s too early for that.

ICAL: 100% NEEDED NOW Yes, iCal is needed (for availabilities). One of the first questions every Hosts asks when they hear about a new platform is “is there iCal?”. The reason is again, that for them it’s an experiment, and they won’t keep availabilities updated for sure. This leads to Guests having to contact dozens of Hosts and getting “sorry, not available” replies, while dates on calendar were available. This is extremely dangerous and it’s still today a problem for Airbnb. Availability information is one of the few things Airbnb shares. They’re not really happy to do that, but they probably realised that not all Hosts accept to be exclusive with them and in order to attract more Hosts, they added the feature. Booking.com is still fighting this, it goes completely against their silos mentality but they were also forced to slowly, unwillingly, give up this data. Expedia still does not have iCal and is seeing little traction in the vacation rental space, in part due to this. No Host right in his mind will list in Expedia (which is Instant Booking Only) without iCal. This is maybe why they spent 3.9 Billion USD to acquire Homeaway. So, let’s definetely use this data they are forced to share.

AVAILABILITIES ARE GOLD It’s early for this kind of reasoning but let’s realise that ultimately the fight amongst Platform is won by those who have the most availabilities. If Origin just gets a few nights per year because most dates are already booked by Booking and Airbnb, there’s not much we can do. I’ve got some ideas on how to fight this battle but this may not be the place or the time, let me know if you’d like to know more.

I apologize if this was unrelated to dev but I think that the underlying business dynamics are important. Again, let me know if I’m out of place or if this should go in Discord.

[wanderingstan]

Thanks @lucadgtrip , this is the right place.

Sounds like on iCal you are 100% that we be able to import iCal from AirBnB (and others). How important do you think it is that we export iCal for other services to ingest? (I think difficulty-wise it's about the same, but just for our prioritization.)

Dapp Developers - Issues with importing iCal

For importing iCal data, do you think we can get away with each Dapp pinging the URL (eg the AirBnB availability URL) on it's own? If tons of people start using Origin dapps, it could look like a DDOS attack.

Last week @nick rightly chastised me for sharing the content of Josh's AirBnB iCal, because it contained guests' names and phone numbers. If these iCal URL's are stored in IPFS (or on chain), then this is also public to the world. These URLs are a true case of "security by obscurity", and by putting these URLs in standard public place all obscurity is removed. ☹️

[lucadgtrip]

The arguments in favour of Exporting iCal too are:

• uniformity: I know of no booking platform which only Imports, so the expected behaviour and capability is that both Import and Export are available. In other words not having Export will rise eyebrows, generate questions, support and so on.
• It encourages users to have Origin as the Main Calendar from which all the others are automatically synced. The main Calendar is the one you keep constantly an eye on, come back often to and improves the chances that Origin users will consider Origin as their main site. Hosts will come back everyday and this is extremely precious. That in turn will make it easier for them to update prices, listing details and so on. Having users constantly on the site opens a whole new set of possibilities. You don’t want Hosts to come back just when a request comes in, find an unfamiliar UX, maybe retrieve the lost password and so on. I guess fidelization is what I’m referring to. iCal Export capabilities is a pre-condition for fidelization, it does not guarantee it but it’s a first step. It’s out of scope but there is a great opportunity in providing Hosts, especially the small ones ignored by paid Channel Managers, a basic and free channel management tool. We may discuss this later on.
• It requires no gas, as other sites will read it.

The only arguments against exporting are:

• at least one more decision has to be taken: will Origin iCal export also bookings (blocked dates) imported from other iCals? Airbnb does not (or didn’t do until recently, I did’t check) and this generates confusion and overbookings. An example: you have two blocked dates in your Airbnb calendar: 10-12 August > booking generated in Airbnb. 12-14 August > booking generated in VRBO, and imported in Airbnb via Vrbo calendar. the second one is NOT exportd by Airbnb. So if you are using Airbnb as your main calendar and export it to, say, Booking.com, in Booking.com the dates 12-14 August are free, and an overbooking is generated.
• Responsibility: Hosts using Origin as their main calendar will blame Origin if something wrong happens (wrong reading, outage, the other site does not import ical well or on time etc..), but this is the same problem every platform has anyway.

If tons of people start using Origin dapps, it could look like a DDOS attack

if you let Dapps ping you have no control on how often they do it and it may be too often. If you don’t let them chose, so Dapps may not be happy with the interval you chose and it centralizes the decision. Anyway iCals are constantly pinged by all platforms, with many users such as Booking.com or Tripadvsor, Origin would be no different. But Origin is different and the platforms may at a certain point boycott (openly or not) Origin iCal calls, so having this done by hundreds of Dapps may mitigate the problem as it would (maybe) be much more difficult for them to knows they are decentralised competitors.

Josh's AirBnB iCal, because it contained guests' names and phone numbers

I see no reason to store nothing more than the dates. Maybe the Airbnb iCals could be sanitised and stripped of the extra data?

[wanderingstan]

@lucadgtrip writes:

I see no reason to store nothing more than the dates. Maybe the Airbnb iCals could be sanitized and stripped of the extra data?

The trick is that there is no server to do the stripping and sanitizing. Of course we could do it on the "necessary evil" bridge server, but I loath to put still functionality into it.

[micahalcorn]

I am going to consider this done since we have a well-baked design document, are iterating on the API, and have real progress on the UI front. We should have some more specific DApp issues for the remaining work.