Thanks for raising this discussion @amanwithwings .
@jthor as an OBRA recipient in Category 5. I feel attacked. LOL but agree that funding in general should be tied to macro objectives.
I will be making a case for:
- Client diversity.
Why? People need to conduct their daily operations when core services go down.
When we first raised our proposal we did get some flack, [SEP 35] [OBRA: Increase governance participation] Improve voting UI/UX with SAFE on mobile about another client.
We can now clearly see that client diversity is important. When core services were suspended, all the various alt-clients had a chance to shine for the specific SAFE activities they supported.
However, key services are sill needed to transact with Safe which brings me to my next point.
- Fallback critical infrastructure.
Why? Again when a core service is stopped for whatever reason vendors NEED fallbacks.
Yes we could clone and run our own txn relayers but this is simply cost prohibitive.
On this point I think we have a few options;
2.a) Petition ecosystem providers to run well known services (Running the Safe Transaction Service – Safe Docs) at a known URL e.g https://txn-relay.safe.optimism.io. This reduces infrastructure burden on small operators and there is increased trust. This also means messages can be pooled.
If I ran my own relayer, it should be HIGHLY UNLIKELY that Safe would want to surface that message on the official UI. Thus we lose some interoperability across various clients.
2.b/ Devise an on-chain method for arbitrary message passing.
3.c/ Deploy a validator like client (rsafetxns) solely responsible for passing messages. Anyone can run this. Possible upside. Truly decentralised. Explore adding additional utility for Safe tokens for staking etc.
I’ve expanded my thoughts earlier on in this thread how this looks like from a vendors implementation perspective. Would appreciate eyes on this as well.