AI translation
I wanted to collect the photos that were sleeping in the guests' smartphones on the same day.
Try the app
photoba（フォトバ）
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
The people taking the most photos at weddings are not professional photographers. They are the guests who attended.
However, most of those photos end up remaining only on each person's smartphone. Days later, people exchange messages in a group LINE saying "can you send me that photo?", some forget to send them, some get tired of it and it fades away. Despite the large number of photos taken, the number that actually reach the newlyweds is quite small.
Meanwhile, existing methods for collecting photos each had their own limitations.
We wanted to achieve both "excitement in the moment" and "photos collected afterward" simultaneously, and crucially, without requiring guests to install anything. That was the starting point for photoba.
The inspiration came when I attended a friend's wedding.
During the reception, guests around me were constantly holding up their smartphones. The entrance, the toast, the entertainment. Everyone was taking dozens of photos from their own angles of the same scenes. But after the ceremony ended, there was no sign of those photos being collected anywhere. A few days later, some people sent them in a group LINE, and that was it. The difference between the number of photos taken and the number that reached the newlyweds just floated in the air, unresolved.
Everyone who was there must have thought "I got some good photos," but there was simply no means to bring them together. There was nothing technically difficult about it, yet it remained unsolved. That inconsistency stuck with me, and I started building it.
You can participate just by scanning a QR code. No app installation, no account registration, no password entry.
Wedding guests are busy people catching up with those they haven't seen in a while. The moment you ask for a 3-step registration process, most won't use it. We prioritized lowering the barrier to participation above all else.
Photo location information (Exif) disappears on the device before being sent to the server. However, we didn't write code to do this.
What we do is redraw it on canvas at 1600px on the long side and re-encode it to JPEG with toBlob. Images redrawn on canvas don't carry over Exif data. The result of resizing for display structurally drops the location information.
If there's a "removal process," bugs can leave traces behind. A structure where it never reaches the server in the first place is safer, we thought. As a side benefit, upload volume decreases, so the venue's Wi-Fi doesn't get congested even if it's weak.
After the retention period passes, photos and events are automatically deleted together. We process this nightly with Cron Triggers.
A subtle frustration with photo sharing services is "not knowing how long things will stay." Especially with wedding photos, you're storing images that include other guests. We wanted it to disappear even if the organizer forgets to delete it.
We also set the retention period to just 7 days for the same reason. We decided that keeping things longer isn't the role of this service.
Photoba reduces images to 1600px on the long side, so the image quality for large prints doesn't remain. Storage is only 7 days.
We write these shortcomings on the site. If we hide them and people use it anyway, they'll just be disappointed when expectations don't match. We thought it was more honest to focus entirely on "excitement at the venue in the moment" and have people use other services in combination for everything else.
Workers / Durable Objects / R2 / D1 / Workers AI. No build process—just static HTML and Workers.
Durable Objects handles real-time display. Each event has one "room," and photos are broadcast via WebSocket to connected screens—this structure aligned perfectly with the "venue screen" use case.
R2 has free egress, so we don't have to worry about transfer volume even if we keep serving images. Being a configuration that individuals can keep running for free was just as important a requirement as the features themselves. You can't entrust photos from an important day to a service you can't sustain.
Currently available as a free beta.
結婚式でいちばん多く写真を撮っているのは、プロのカメラマンではありません。参加したゲストです。
ところが、その写真のほとんどは各自のスマホに残ったまま終わります。後日グループLINEで「あの写真ちょうだい」と言い合い、何人かは送り忘れ、何人かは面倒になって流れる。撮った枚数のわりに、新郎新婦の手元に届く枚数はかなり少ない。
一方で、写真を集める既存の方法にはそれぞれ壁がありました。
「その場で盛り上がる」と「あとで手元に集まる」を同時に、しかもゲストに何もインストールさせずにやりたい。それがphotobaの出発点です。
きっかけは、友人の結婚式に出席したときのことでした。 披露宴のあいだ、周りのゲストはずっとスマホを構えていました。入場、乾杯、余興。同じ場面をそれぞれの角度から、何十枚も撮っている。ところが式が終わったあと、その写真がどこかに集まる気配はありませんでした。数日後にグループLINEで何人かが送って、そこで止まる。撮られた枚数と、新郎新婦の手元に届いた枚数の差が、そのまま宙に浮いたままになっていました。 その場にいた全員が「いい写真が撮れた」と思っていたはずなのに、それを持ち寄る手段だけが、たまたま誰も持っていなかった。技術的に難しいことは何ひとつないのに解決されていない、という点が引っかかって、そのまま作りはじめました。
QRを読むだけで参加できます。アプリのインストールも、会員登録も、合言葉の入力もありません。
結婚式のゲストは、久しぶりに会った人と話すのに忙しい人たちです。そこで3ステップの登録を求めた時点で、大半は使ってくれません。参加のハードルを下げることを最優先にしました。
写真の位置情報(Exif)は、サーバーに送る前に端末側で消えています。ただし、そのためのコードは書いていません。
やっているのは、canvasに長辺1600pxで描き直してtoBlobでJPEGに再エンコードすることだけです。canvasで描き直した画像にはExifが引き継がれません。表示用の縮小をした結果、位置情報が構造的に落ちる。
「消す処理」があると、バグったときに消え残ります。そもそもサーバーに届かない構造のほうが安全だと考えました。副次的に、アップロード量が減って会場のWi-Fiが弱くても詰まりにくくなっています。
保存期間を過ぎると、写真もイベントもまとめて自動削除されます。Cron Triggersで毎晩処理しています。
写真共有サービスで地味に困るのが「いつまで残るのか分からない」ことです。特に結婚式の写真は、写り込んだゲストの分まで預かることになります。主催者が削除を忘れても消えるようにしておきたかった。
保存期間を7日と短くしたのも同じ理由です。長く残すことは、このサービスの役目ではないと割り切りました。
photobaは長辺1600pxに縮小するので、大きく印刷する画質は残りません。保存も7日だけです。
サイトにもこの欠点を書いています。隠して使われても、期待と違えば結局がっかりされるだけです。「当日その場の盛り上がり」に振り切って、それ以外は他のサービスと併用してもらうほうが正直だと考えました。
Workers / Durable Objects / R2 / D1 / Workers AI。ビルド工程はなく、静的HTMLとWorkerだけです。
リアルタイム表示はDurable Objectsが担当しています。イベントごとに1つの「部屋」を持ち、WebSocketで接続中のスクリーンへ写真をブロードキャストする——という構造が、そのまま「会場のスクリーン」というユースケースに一致しました。
R2はegressが無料なので、画像を配信し続けても転送量を気にせずに済みます。個人が無料で公開し続けられる構成であることは、機能と同じくらい重要な要件でした。続けられない前提のサービスに、大事な日の写真は預けられません。
現在は無料ベータ版として公開中です。
