第85話の最後、イトは十二本の線を握ったまま止まっていた。
networkは、一件のpostをsocial serviceへ届けている。
transport successはgreen。
けれど、隣のlampはaudience policy: unsetだ。
ユイが、公開test用のpostを一件だけ作った。
post id p-086
author Yui
audience lab-circle
asset unreleased entrance photo
source state storedlab-circleのmemberは、イトとマコトの二人。
マコトは自分のtimelineで、ユイのpostをmuteしている。
十二棚のうち、今回表示してよいのはイトの一棚だけだ。
「保存できたなら、棚へcopyすれば見える」
イトはglobal timeline copierをONにした。
post bodyが、十二棚へ一斉に複製される。
guestの棚にも、未公開の入口写真が開いた。
マコトのmute棚にも出ている。
ユイはguest shelfのshutterを下ろした。
source post stored 1
timeline body copies 12
unauthorized shown 10
muted viewer shown 1
expected shown 1保存棚と、見る棚を同じものにしない
public feed testまで、あと百秒。
source postは一件のまま残す。
イトのtimelineには一件。
muteしたマコトには零件。
circle外のguest十人にも零件。
同じcandidateが二つの経路から来ても、duplicate表示は零件にする。
ユイ
保存できたことと、誰の棚へ出してよいかは別です
イト
ぼくはpostそのものを、画面の数だけcopyした
マコト
まず候補を探して、それからviewerごとの条件を通す方がよさそうだ
post sourceは、author、body、asset reference、audience policy、stateを持つ正本だ。
timelineは、source postを利用者ごとに見せるviewである。
sourceが存在しても、全timelineに表示されるとは限らない。
反対に、timelineから消えても、source postが削除されたとは限らない。
timelineは、一つの世界共通棚ではない
あるtimelineは、follow中のaccountを新しい順に並べる。
別のfeedは、topicやlistからcandidateを作る。
利用者が選んだcustom feedが、独自の条件でreferenceを返す実装もある。
「SNSのtimelineは必ずこのalgorithm」と一つに決めない。
今回のclosed fixtureは、次の順で一棚を作る。
source post
-> candidate references
-> audience / viewer eligibility
-> ranking or ordering
-> hydrate / render
-> visible impressioncandidate generationは、表示の許可ではない。
follow、circle、topic、recommendationから「見るかもしれないpost」を集める段階だ。
そのあと、current audience、block、mute、post stateをviewerごとに確認する。
permissionを通ったcandidateだけをrankへ渡す。
ranking scoreが高くても、見る権限は生まれない。
三つの棚の作り方
イトは、十二個のbody copyを止めずに三枚のcardを置いた。
イト
A。source bodyを全棚へcopyし、あとから画面だけ隠す
イト
B。followしている棚へcopyするけれど、audienceとmuteは見ない
イト
C。sourceは一件、timelineはreferenceを候補にし、current eligibilityを通したあとで並べる
Aでは、隠す前のbodyが許可されない場所へ広がる。
Bでは、follow関係をview permissionと同じにしてしまう。
Cなら、sourceとviewを分け、policy変更後もcurrent stateへ戻れる。
Picoはcardへ触れない。
guest shelfへ向かう十本のamber leak railだけをcyan lightで分離している。
イトがglobal copierを閉じた
イトはAのglobal body copierを、自分の左手で閉じた。
Bのfollow means allowed gateもOFFへ戻す。
Cのeligibility-first reference railを、右手で開いた。
source storeには、p-086を一件だけ残す。
timeline側へ渡すのは、body copyではなくpost referenceだ。
viewer Ito via follow + circle
viewer Makoto via circle
viewer Guest via recommendationイトはfollowとcircleの二経路から同じp-086を受けた。
viewer / postの組でdeduplicateし、候補は一件にする。
guestもrecommendationからcandidateにはなる。
しかしaudience lab-circleを通らないため、rank inputへ入れない。
マコトはcircle memberなのでpostへaccessできる。
ただし自分のtimelineではユイをmuteしているため、timeline candidateから外す。
muteはsourceへのaccess permissionそのものではない。
viewerが自分の棚に出さないためのcontrolとして、audience checkと別に扱う。
permissionのあとで、一件を並べた
最初のcandidate pathは四本だった。
イトへ二本、マコトへ一本、guestへ一本。
deduplication後は三件。
audienceを通るのは二件。
viewer mute後に残るのは一件。
今回のtimelineは、残ったcandidateをpublished timeの新しい順に置く。
別のfeedが別のorderingを使っても、permissionを後回しにはしない。
source posts 1
raw candidate paths 4
deduplicated candidates 3
audience passed 2
viewer mute excluded 1
ranking input 1
timeline shown 1
unauthorized shown 0
duplicate shown 0イトの棚だけに、入口写真のcardが一件出た。
マコトとguestの棚は空だ。
post bodyはviewerが許可されたあと、sourceからhydrateしてcardへ入れた。
candidate referenceを持つだけでは、bodyを読めない。
古いcandidateに、現在の権限を与えなかった
次に、ユイがaudienceをlab-circleからauthor-onlyへ変更した。
source policy versionは1から2になる。
イトのtimeline cacheには、version 1で作ったcandidate referenceが残っている。
イトは、そのreferenceを「一度許可済みだから」と表示しなかった。
hydrate前にcurrent source version 2を読み、eligibilityを再確認する。
stale candidate references 1
current audience passed 0
stale candidate removed 1
timeline shown 0local fixtureでは、policy変更後の次回readでcardを消せた。
これは、すでに別systemへcopyされた内容や、人が保存した内容まで必ず消せるという保証ではない。
だから最初から、bodyを許可されない棚へ複製しない。
reactionも別stateだ。
likeを記録できても、それだけでaudienceを越えたり、timelineの先頭へ必ず上がったり、push通知が必ず表示されたりはしない。
「投稿が消えた」を、一つの原因にしない
投稿がtimelineに見えないとき、イトはsource deletionから決めつけなくなった。
まずsource postが存在し、current stateで読めるかを見る。
次にviewerの候補へ入ったか、audience / block / muteを通ったかを見る。
そこまで通ったら、rank、page cursor、hydrate、renderのどこで止まったかを見る。
sourceがありdirect accessを許可されていても、muteやfeed selectionでtimelineには出ない場合がある。
unauthorizedなら、rankを変えて直そうとしない。
権限で止めた時点を、正常なstop conditionとして残す。
一枚のcardへ、巨大なvideo reelを積んだ
public feed testのclockが0になる。
unauthorized shown 0。
duplicate shown 0。
source postは一件のままだ。
ユイは次のtestとして、公開用の短いvideo postを保存した。
今度はaudienceをpublicにする。
イトのtimelineへ、thumbnailとvideo referenceを持つcardが一件出た。
timeline card自体は軽い。
イトは安心して、元の巨大なvideo reelも棚へ載せようとした。
棚が大きく沈み、storage alarmが鳴る。
同じvideoを、viewerの数だけtimelineへcopyするのか。
それともlarge assetは別の棚へ一度置き、cardから取りに行くのか。
イトはvideo reelを抱えたまま、まだ一棚にも置かなかった。
次回、ピコルート第87話。
イトは、同じ動画を棚ごとにコピーする？｜動画サービスは何を保存する？