@april If that's something you want, I would start from making messages unforwardable, and then add forwardability as an extension.
-
@april If that's something you want, I would start from making messages unforwardable, and then add forwardability as an extension.
-
April The Pink ⋆☾╶⃝⃤☽⋆replied to Jenniferplusplus last edited by@jenniferplusplus maybe add two types of signatures instead? one that includes a instance host and one that doesnt?
-
Jenniferplusplusreplied to April The Pink ⋆☾╶⃝⃤☽⋆ last edited by
@april That all has to happen in the http headers, and by my (quick) read of the extension mechanism, it would be hard to convey that there are extended headers the recipient should consider.
I was imagining a message signature that includes the destination host in the base level protocol, and an extension to define and include a forwardable token in the message body.
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
@april Forwarders would have to sign the forwarded message themselves, but the token would authenticate the original author and authorize forwarding.
-
April The Pink ⋆☾╶⃝⃤☽⋆replied to Jenniferplusplus last edited by@jenniferplusplus my idea was to have two different signatures in the base spec, but that might overcomplicate it
-
Jenniferplusplusreplied to April The Pink ⋆☾╶⃝⃤☽⋆ last edited by
@april That would also work, but it does add complication. I really appreciate the focus on ease of implementation. And it seems like versia is probably a lot more amenable to iterative implementation than AP is, which would be extremely helpful. Double signing in the base spec seems to run counter to those goals.