A peek packet is very unlikely to exceed the MTU, since it's basically just a path. But the correlated %page response is at a much greater risk, since it includes that path and the response data fragment.

I think the best approach is to impose an upper bound on path length here (based on a full-size data fragment), and fallback to a content addressing layer (a poke requesting that the path be re-bound temporarily under a hash).

:: max data segment
> :(add 1 8 64 64 2 1.024)
1.163
:: remainder for encoded name
> (sub (sub 1.472 8) 1.163)
301
:: encoded-name overhead
> :(add 1 16 4 1 4 2)
28
:: max path
> (sub 301 28)
273

It would probably be fine to punt on the content addressing fallback and just check the overall encoded name-length:

?.  (lte 301 (rig (met:plot (en:name nam) 3))
  ::  slog peek path too long, give blocked response
:: issue %peek