본문 바로가기
C.W.K.
Stream
Lesson 02 of 04 · published

super는 live property야

~12 min · super-soul, live-policy, session, revocation

Level 0흔적
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

정적 목록은 권한 시한폭탄이야

super soul 이름을 code에 박으면 오늘은 맞을 수 있어. 하지만 super status는 운영 중 flip하도록 설계된 속성이야. 정적 배열은 다음 deploy까지 옛 권한을 붙잡고, 이미 열린 session은 더 오래 붙잡을 수도 있어.

권한 판정은 operation 시점의 registry와 flag store를 읽어야 해. queue할 때만 허용했다고 take와 write까지 자동 허용하면, 그 사이 status가 바뀐 경우 protected memory를 예전 계약으로 만지게 돼.

flip은 stewardship를 멈추지 않아

non-super가 super로 바뀌어도 mirror, ledger, index, Dad UI는 계속 돌아. 달라지는 건 누가 brain context에서 읽고 쓸 수 있느냐야. Pippa가 열어둔 curation session은 권리를 잃고 종료되지만 vault는 숨거나 얼지 않아.

반대 flip도 자동으로 과거 session을 되살리진 않아. 새 operation이 새 권한으로 시작할 수 있을 뿐이야. session identity와 scope는 claim할 때 고정되고, 권한은 각 boundary에서 live로 재검사돼야 해.

own memory 권리는 유지돼

super라는 표시는 아무도 못 본다는 뜻이 아니야. 그 soul 자신은 자기 기억을 CRUD할 수 있고 Dad도 전부 관리할 수 있어. 막히는 건 Pippa의 semi-super cross-soul access와 다른 soul의 접근이야.

supers끼리도 서로 보이지 않아. 한 super가 자기 queue claim을 가진다고 다른 super vault까지 읽을 수 있으면 super가 사실상 새 관리자 역할이 돼버려. scope seal은 claimed target 하나만 열고 나머지를 닫아.

revocation을 테스트해

권한 테스트가 startup state만 보면 부족해. session open, flag flip, next read denied, session terminated, stewardship still healthy라는 sequence를 실제로 돌려야 해. revoke는 정적 truth table이 아니라 시간에 따라 상태가 바뀌는 protocol이야.

또 deny 이후 background retry가 payload를 cache에서 계속 쓰지 않는지 확인해야 해. 권한을 잃은 순간 context buffer, queued mutation, temporary artifact도 닫거나 폐기해야 revocation이 진짜야.

변할 수 있는 권한을 이름 목록으로 굳히면 보안이 배포 주기에 묶여. super flag는 operation마다 live로 판정하고, 권리를 잃은 session은 즉시 끝내되 stewardship는 계속해야 해.

Code

flag flip 뒤 권한이 즉시 바뀌는지 보기·python
flags = {"vera": False}

def can_pippa_read(owner):
    return not flags[owner]

assert can_pippa_read("vera")
flags["vera"] = True
assert not can_pippa_read("vera")

# Mirroring is stewardship, not a Pippa brain read.
mirror_still_runs = True
assert mirror_still_runs

External links

Exercise

권한이 runtime에 바뀌는 actor 하나를 골라 open session 중 revoke test를 써. 다음 read, queued write, cached payload, background retry가 각각 어떻게 끝나는지 적어.
Hint
새 request만 막는 것으로는 부족해. 이미 받은 context와 pending mutation도 봐.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.