search

OpenHospitalityNetwork / fedi-trustroots

Next generation federated hospitality exchange platform
https://openHospitality.network
GNU Affero General Public License v3.0
23 stars 3 forks source link

Indirect hosting requests #30

Open mariha opened 3 years ago

mariha commented 3 years ago

Right now travelers choose a host and write direct message to them requesting to stay. It is not possible to post indirect hosting requests, broadcasted in the area a person is traveling to so that hosts could choose the traveler and volunteer to offer a stay.

Something like:

I travel and publish: Who can host me? Everyone nearby in the network can see it and someone answers: come over to my home, we’ll be waiting this evening for you.

weex commented 3 years ago

Stating this as a problem:

There's no way to request hosting in a specific area without selecting a particular host. This creates friction for the traveler as they must search and request hosting from multiple hosts.

One question, in this area-based request model, would hosts be able to see if other hosts had responded?

mariha commented 3 years ago

I think the problem here is a bit different though...

From traveler's perspective: When traveling (by bike, hitchhiking, ...) it is very hard to predict when exactly a person will arrive at a given place. Many unexpected things can happen on the way (upfront wind, flat tires, unpaved road when asphalt was expected, too beautiful places to just pass them by without stopping for a while, ...). Trying to make it to the point on time creates a lot of pressure on a traveller and whole joy and freedom of traveling is lost. It's a matter of politeness to ask for a stay with a few days of notice before one arrives at someone's home and knocks the door.

From hosts perspective: Plans keep changing and sometimes hosts may not want to commit a few days or weeks ahead of time for the exact day to be at home and host someone. They prefer to reject or not answer at all. If they receive direct message they may feel obligated to host/answer.

With indirect requests, there is less pressure on a host to answer, this makes it ok for a traveler to ask just a few hours before arriving, a host could answer based on plans for today/tomorrow not a week or month ahead of time.

This flow of a request gives also hosts more freedom to choose their guests.

One question, in this area-based request model, would hosts be able to see if other hosts had responded?

I'd make responses invisible to them, so that more then one offer can be made and a guest had a chance to choose a host too. When both sides accept each other, I'd make it visible to other hosts so that they know there is no need any more to offer a stay.

A note on the process: For sure, it's good to understand the context and why a feature is desired and what problem(s) it solves for the users. As it is here though, we are reverse engineering the solution to explain what issues it addresses. I can imagine if we wanted to state issues as problems to solve, for this one we'd have many entries of problems. It seems more intuitive to me to state what we plan to implement and why, and then leave to the developer freedom to choose implementation details (technical solution).

Explaining why? of a feature leaves space to propose other solutions, I think though before implementation is started we'd rather agree on what is there to implement and how the functionality is supposed to work.

weex commented 2 years ago

We discussed this yesterday in the meeting and I wanted to write here about what may go on step by step for the user:

  1. Traveler needs accommodation at some point in the near future centered on some lat/long. So they go to their home instance, drop a pin on the map and enter an ETA to create the request.
  2. Hosts who are within some range of the lat/long are notified of the request immediately.
  3. If the request is not filled within some period of time, the initial notifications are expired and the range is expanded to generate a new set of notifications which more hosts may see.
  4. For example, a host in this expanded notification sees the request and responds to the traveler.

Including federation in the process, the lat/long, range and expiration time would be sent as a hosting request to any connected instances, which would notify hosts local to that instance.

Edit: This kind of step-by-step user story might be better placed in with wiki. Feel free to edit this post in the meantime. I just wanted to get this idea down somewhere.