How to quote notes?

Friendica has got a functionality like Twitter has got as well: Resharing an item with an additional quote to it. I now want to build this in AP as well. I thought of using the “attachment” value for this:

            [attachment] => Array
                (
                    [0] => Array
                        (
                            [type] => Note
                            [id] => https://pleroma.soykaf.com/objects/df9c8bec-ba84-41d8-a955-3fbe0d88ed89
                        )

                )

I’m not totally sure if this is 100% AP conform, but I don’t know a better solution. What do you think?

1 Like

I’m definitely interested in this for Socialhome. I wonder if any platform implements something similar in AP already, Hubzilla maybe?

So you would send out something like this?

{ Create 
   { type: Note
     id: https://quote
     attachment: [{
       type: Note
       id: https://quoted-note
     }]
   }
} 

The other option is to add the Note as an attachment to the Announce?

{ Announce
  { type: Note
    id: https://quoted-note
  }
  attachment: [{ 
     type: Note 
     id: https://quote
  }]
}

I somehow feel the latter might be semantically closer to “share with a note attached”. Of course the risk is that most platforms will just ignore the attachment. On the other hand, if one sends a Note with an attachment, it could be that most platforms lose context with the quoted note.

1 Like

My plan is simply add a link to the original note in the quote message. This would be backwards compatible.

1 Like

I guess it makes more sense that way, you’re probably right. Better to ensure the note gets delivered even if it loses the attachment (on non-supported platforms who ignore it) than lose the note and just show the announced note as a normal announce.

1 Like

We ended up with two mechanisms - share and embed. The first translates to Announce and doesn’t allow commentary. The second does, and would be similar to what Michael describes using an attachment (Create->Note); although we actually embed the object in the content.

There were a number of permission paradoxes revealed by the ‘share’ (Announce) method so this has been downplayed in Hubzilla and removed entirely from Zap. ActivityPub sites will not have discovered these issues because they don’t have working permissions. Assuming they widely adopt some form of security through obscurity like ocap (don’t even get me started) they’ll quickly discover Announce is fatally flawed so alternative mechanisms will soon be required.

[edit: ocap itself isn’t the problem, but the proposed implementations are. Security and permissions requires a bit more thought than a design pattern cookbook and some random numbers.]

1 Like