Trying it out is one thing, but operating and admining an instance is another. (And with the Redis requirement, it’s also not all that easy; cf @rosano in https://community.remotestorage.io/t/call-for-feedback-contributions-paas-as-an-adoption-strategy/685.)
Case study: the new-ish joint ACM/IEEE chapter for Austin put up a vibe-coded site about a month ago: https://local.acm.org/acm-austin/ These are volunteers, and this is approximately the amount of effort they’re interested in dedicating to this.
For the real-time event countdown on the landing page, they have hardcoded placeholder data to get around the fact that they don’t have API access to Luma and/or Meetup. (As a consequence, the current countdown is wrong; there’s an event today at 6PM, but the countdown shows 34+ days before the next one, due to [1].) Luma provides an iCal link (view-source:https://api.luma.com/ics/get?entity=calendar&id=cal-HidBA3hMcIwKB1L), but not RSS. (It doesn’t support CORS, but CORS workarounds are widely available.)
If it were easy to demonstrate and validate that Sockethub could handle the ICS payload (by copying-and-pasting the contents, à la tools.simonwillison.net, onto the Sockethub landing page and checking the output) and there were a build that worked in the browser (or, bonus, if the aforementioned widget were also embeddable and not just on the sockethub.org landing page), then I could show up tonight and say, “Look, here’s Sockethub. Use it.”
(This is only exercising like 30% of the functionality and current value proposition of Sockethub, and they could just use an ICS parser library from NPM, but who cares.)