Conversation

Notices

1. Alex Gleason (alex@gleasonator.com)'s status on Friday, 26-Jan-2024 03:44:13 JST Alex Gleason

   • silverpill
   • Dave
   @97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322 Mastodon API is not ActivityPub. It's a REST API inspired by Twitter's legacy API. Old versions of GNU Social were even API-compatible with Twitter, and you could use GNU Social client apps to interact with Twitter. Mastodon developed this idea out separately from ActivityPub. In fact Mastodon was not even originally an ActivityPub server - it added that later.
   
   Ditto exposes zaps in a way Mastodon API clients can implement, but it doesn't solve the ActivtyPub problem. Mostr does emit a "Zap" activity for zap receipts, but it doesn't actually contain all the necessary information you would need to verify the zap: https://gitlab.com/soapbox-pub/mostr/-/blob/main/src/activitypub/transmute.ts?ref_type=heads#L412-429 To complete it, I would need to add a stringified 9734 event in there and other essential fields like the preimage. I didn't add these things because I didn't understand how zaps actually work, and I'm only now starting to learn.
   
   The main issue with ActivityPub zaps is that the zap spec itself (NIP-57) requires a Nostr event to be sent to the LNURL callback in order to get a receipt. To build that Nostr event you need a keypair for the user. The receipt is then delivered to a Nostr relay. This essentially means that to implement Zaps, you have to implement Nostr. The only way around it is to ignore NIP-57 entirely and just go straight to sending Lightning payments. But then there's no way to get the receipt on the ActivityPub side, and thus no dopamine rush notification or any statistics or context about zaps on the protocol at all.
   
   Either a new spec would be required, for zappers like Alby to support an "activitypub" optional field in the lnurl callback (as they do for "nostr") and then emit an Activity of the receipt back to the AP server, or AP servers like Mastodon and Pleroma will have to implement basic Nostr features (maybe as a facade) to work within the existing system.
   
   cc @silverpill @dave
   • silverpill (silverpill@mitra.social)'s status on Friday, 26-Jan-2024 03:44:11 JST silverpill

     in reply to

     • Dave

     @alex @dave @97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322

     >emit an Activity of the receipt back to the AP server

     This sounds like the best solution, but then lightning node will have to implement AP actor, right?

     It should be possible to create actor-less activities with FEP-ef61. I need to think about it.

   • Alex Gleason (alex@gleasonator.com)'s status on Friday, 26-Jan-2024 04:26:15 JST Alex Gleason

     in reply to

     • silverpill
     • Dave
     @silverpill @97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322 Should we convince Alby to implement this? They would probably do it. Curious what @dave things. I'm still researching keysend trying to understand possible alternatives. This is an LNURL flow.
   • silverpill (silverpill@mitra.social)'s status on Friday, 26-Jan-2024 04:26:15 JST silverpill

     in reply to

     • Dave

     @alex @dave @97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322

     Yes, I think it is worth trying.

     Also, you might be interested in this: https://github.com/getAlby/lightning-browser-extension/pull/826