From listing to handover / Від оголошення до вручення

English · Українська нижче

A parcel has three people behind it

Imagine you want to send a book to someone close to you. A traveler is already going in the right direction. You find each other, but there are still questions: what is inside, when can you meet, and who will collect it?

I'm building RÓSA around those questions. Here's the intended journey, with a simplified example rather than a real delivery story.

Before anyone takes the parcel

• The sender describes the item and adds photos that show its contents and condition.

• The traveler publishes a route and available capacity, then checks whether the parcel fits the trip.

• The recipient joins the agreement and confirms the receiving arrangements.

A listing can start without a named recipient. The recipient needs to join before the three-person agreement can be completed. One account can send, travel and receive in different situations.

A BOOK'S JOURNEY

Describe + photograph
         ↓
Find a suitable trip
         ↓
Discuss the details
         ↓
All three people agree
         ↓
Reserve capacity

Why two handover codes?

There are two different moments to confirm: the sender gives the item to the traveler, and the traveler gives it to the recipient. RÓSA's test flow uses a separate one-time code for each handover.

The code records a confirmation. It does not inspect the contents or prove that an item is undamaged. People still need to check the item and record its condition.

HANDOVER 1
Sender → traveler
Inspect + confirm

HANDOVER 2
Traveler → recipient
Inspect + confirm

And if plans change?

Before agreement, listing edits have a history. After agreement, an update should be visible as a comment rather than silently changing what people accepted. A delayed trip and a damaged item need different responses; the return and dispute procedures are still being developed.

Where this stands: the audit of 11 September 2026 found these core rules in the test product. Real payments and document verification are not connected, and readiness for actual deliveries is not confirmed. This explains the product being built, not an invitation to hand over a parcel today.

For me, the useful part is keeping all three people in the same conversation about what happens next.

УКРАЇНСЬКОЮ

За кожною посилкою стоять троє людей

Уяви: хочеш передати книжку близькій людині. Мандрівник саме їде в потрібному напрямку. Ви знайшли одне одного, але лишилися питання: що всередині, коли зустрітися і хто забере річ?

Навколо цих питань я й будую RÓSA. Ось задуманий шлях на простому прикладі. Це пояснення, а не історія вже виконаної доставки.

До того, як хтось візьме посилку

• Відправник описує річ і додає фото, на яких видно вміст та стан.

• Мандрівник публікує маршрут і доступне місце, потім перевіряє, чи підходить посилка до подорожі.

• Отримувач долучається до домовленості та підтверджує умови отримання.

Оголошення можна створити без зазначеного отримувача. Але для завершення погодження трьох учасників він має долучитися. Один акаунт може відправляти, подорожувати й отримувати в різних ситуаціях.

ШЛЯХ КНИЖКИ

Описати + сфотографувати
         ↓
Знайти відповідну подорож
         ↓
Обговорити деталі
         ↓
Отримати три згоди
         ↓
Зарезервувати місце

Навіщо два коди передачі?

Є два різні моменти: відправник передає річ мандрівнику, а мандрівник отримувачу. У тестовому сценарії RÓSA для кожного вручення є окремий одноразовий код.

Код записує підтвердження. Він не перевіряє вміст і не доводить відсутність пошкоджень. Людям усе одно потрібно оглянути річ і зафіксувати її стан.

ПЕРШЕ ВРУЧЕННЯ
Відправник → мандрівник
Оглянути + підтвердити

ДРУГЕ ВРУЧЕННЯ
Мандрівник → отримувач
Оглянути + підтвердити

А якщо плани змінилися?

До погодження зміни оголошення мають історію. Після погодження оновлення має бути видимим коментарем, а не непомітною заміною того, що люди прийняли. Затримка подорожі й пошкодження речі потребують різних дій. Процедури повернення та спорів ще розробляються.

Поточний стан: аудит від 11 вересня 2026 року знайшов ці основні правила в тестовому продукті. Реальні платежі й перевірка документів не підключені, готовність до справжніх передач не підтверджена. Це пояснення майбутнього сервісу, а не запрошення передати посилку сьогодні.

Для мене головне, щоб усі троє розуміли, про що домовилися й що відбуватиметься далі.