Can you install amp-script (move past the error before this one) in a situation where SSR is enabled?

Thats a good point. While this check exists for bind, <amp-script> is not valid within amp4email so it is likely unnecessary.

Although technically one could opt-in to SSR mode (and self-host the runtime to make their origin a whitelisted ssr-er) and then get past the earlier error.

🤷

In the latter case, is there a reason they should not be able to opt into the amp-script protocol?

Yep! Because in the SSR case, it is the viewer that actually does the fetch. We can't expect a viewer to know how to handle amp-script: scriptId.fnId

For my learning: Is multiple dot call left out to limit scope?

As written, the dot is meant to be a separator for ampscriptId and fnIdentifier. It isn't actually reaching into an object. For that reason only a single dot is valid.

Note: we could pick essentially any separator as long as the separator isn't a valid part of a js ident

Is testing for bad inputs handled in worker dom? Also can that call an identifier with dots?

I think I answer that in a response to an earlier question, let me know if I missed something!
#29329 (comment)

I may have missed if there are test cases for this in worker dom, but I mean strings that are empty or otherwise not valid js variable names, i.e. 123 or anything containing odd symbols.

We don't run the function name they pass directly into an eval() or anything like that. worker-dom exposes a function called exportFunction(string, handle) so that devs can specifically mark functions for export. As long as the string they pass in matches a string that was exported it'll work.

That is an interesting point that technically invalid identifiers can pass through this unharmed, I'm not convinced thats a bad thing.

Why have this intermediary function on AmpScriptService at all?

There's only a single caller but if you want to avoid the boilerplate you could also hook into the internal actions API e.g. registerAction.

This would actually solve a lot of interesting problems around args parsing so I'd love to make it work.
I'm not seeing a straightforward way to pipe through the return value though

Ah yea, I guess executeAction could work but not sure it's a net win actually.

Yeah. Calling executeAction would mean I'd still need to locate the correct element, so wouldn't help much here. A nice aspect is that if I registered the action, we'd get part (1) of this issue implemented for free: #24763

Also, I could imagine us moving in a direction eventually where devs pass a mixture of literal arguments/ amp-state arguments into the function. I skirt the issue by banning it entirely, but if we utilized the actions parser it could be easier to implement. This would become especially important if we wanted to make amp-script functions accessible from bind expressions.

Interop with bind expressions would let devs write a bound src with amp-state vars and have it automatically updated when the state variable is updated.

<amp-list [src]="amp-script:fns.fetchListData(filterArgs)">

The current workaround requires chaining a list.refresh() action after the setState action.