@cryptix @keks good points. yes EBT definitely needs to know who called it, optimizations (request-skipping) and safety features (blocking) depend on that.

I thought that maybe gossip.ping would use that too, but only the client side remembers the ping.
This could benefit from tracking who's called, though.

Hmm, there are several options available to us here:

1. add a fixed field to the call args - so if your method was function (opts) {...} there would now be opts.auth. This would mean that functions taking strings would be unable to know the caller. Also, this mixes application data with system data, which is undesirable, and a security footgun (would need to check that if an application tries to pass opts.auth that it doesn't work)

2. add a field to the call data that is the context: function (opts) { this.id // caller } this is actually how it currently works. For process plugins, the parent process would have to pass this information in with the call, but obviously remote muxrpc get this from the authentication system (shs). A raw muxrpc call message, which creates the request has a json body: {type, name, args} we could just add context to that? should it just be the string? or will we need to add more thing to that ever? (fingers crossed that we don't!)

Hmm, @keks already gave some good examples of why we might need more fields - boolean of whether it was called by self (or a friend etc).