GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    silverpill (silverpill@mitra.social)'s status on Monday, 04-Aug-2025 01:33:41 JST silverpill silverpill
    • Marius

    @Marius I think they do it for compatibility with Mastodon. How would you represent a photo-post? An Image? Or a Note with image property?

    In conversation about 5 months ago from mitra.social permalink
    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Friday, 08-Aug-2025 22:17:57 JST silverpill silverpill
      in reply to
      • marius
      • Marius

      @Marius cc @mariusor

      In conversation about 5 months ago permalink
    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Saturday, 09-Aug-2025 03:44:20 JST silverpill silverpill
      in reply to
      • marius
      • Marius

      @mariusor @Marius The problem with submitted public keys is that client controls the secret key. It can make signed requests and retrieve private objects, bypassing the server.

      If the owner is not verified, the client can impersonate other actors on the server and retrieve private objects that are accessible to them but not to the current user (e.g. DMs).

      In conversation about 5 months ago permalink
    • Embed this notice
      marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:22 JST marius marius
      in reply to
      • Marius

      @silverpill and this happens because the purpose of the library and all the reference tooling around it is to deal with ActivityPub and only that. There's no additional APIs (well, except for all the CLI stuff I just mentioned :D) that can make the the client/servers have better UX for key rotation.

      Nothing prevents users to invent their own mechanism when they use it though.

      @marius

      In conversation about 5 months ago permalink
    • Embed this notice
      marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:23 JST marius marius
      in reply to
      • Marius

      @silverpill the reply above is for Updates, but for Create, usually we send the actor without any key and the server generates a key pair automatically.

      @marius

      In conversation about 5 months ago permalink
    • Embed this notice
      marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:25 JST marius marius
      in reply to
      • Marius

      @silverpill there's no mechanism to stop you updating an actor's public keys, but that breaks an assumption that's being made in the GoActivityPub logic, which is that key rotation is handled out of band using CLI tools that handle both the private key and update the Actor.

      So, after such an update there would be a mismatch between the private key used by the internals of the library and the key retreived by other servers to check.

      I haven't found a clean way to do this operation with a better UX sadly, so CLI is all we have.

      @marius

      In conversation about 5 months ago permalink
    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Saturday, 09-Aug-2025 03:44:32 JST silverpill silverpill
      in reply to
      • marius
      • Marius

      @mariusor @Marius

      >GoActivityPub servers are just (mostly)dumb pipes to the web and the rest of the fediverse.

      Oh, I have a question regarding this. How do you deal with public keys in client-generated activities?

      For example, can I Create an object with publicKeyPem property where I am the owner?
      What if the owner is another actor?

      In conversation about 5 months ago permalink
    • Embed this notice
      marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:33 JST marius marius
      in reply to
      • Marius

      @silverpill and if you remember from last time we talked about stuff, the structure of these operations is decided in the clients, because the GoActivityPub servers are just (mostly)dumb pipes to the web and the rest of the fediverse.

      @marius

      In conversation about 5 months ago permalink
    • Embed this notice
      marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:34 JST marius marius
      in reply to
      • Marius

      @silverpill so for the Pixelfed use case where usually there are multiple images, I upload them as separate images, and then aggregate them as attachments to a Note.

      I think the difference to Mastodon&co. is that for GoActivityPub services, the images are not embedded and exist as stand-alone, dereferenceable objects

      @marius

      In conversation about 5 months ago permalink
    • Embed this notice
      marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:35 JST marius marius
      in reply to
      • Marius

      @silverpill the old way is just an Image with summary and name: https://marius.federated.id/uploads/basking-snick

      Which then can be set as an attachment to a note.

      The new way is slightly more complicated and I upload multiple versions that get set as URL values on an original Image:

      https://marius.federated.id/uploads/bread-top-july

      This one can also be attached to a note or whatever.

      (if you view them in browser you get a raw image for the first, and an html documen for the second) With json+ld accept header you get the raw objects.

      @marius

      In conversation about 5 months ago permalink

      Attachments



    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Saturday, 09-Aug-2025 04:39:00 JST silverpill silverpill
      in reply to
      • marius
      • Marius

      @mariusor @Marius Example:

      { "type": "Create", "actor": "https://social.example/actor1", "object": { "type": "Key", "owner": "https://social.example/actor2" "publicKeyPem": "..." } }

      This key is created by actor1, who controls the secret key. But it is owned by actor2. This means actor1 can sign requests using the secret key and everyone will think they are signed by actor2.

      In conversation about 5 months ago permalink

      Attachments



    • Embed this notice
      marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 04:39:02 JST marius marius
      in reply to
      • Marius

      @silverpill I can't really understand your example. The client doesn't have access to other actor's private keys, so it shouldn't be able to sign requests. Or you're thinking for the case of a client that is used by multiple users, *and* it stores private keys...

      My clients generally use only OAuth2 for authorization to the service their users belong to and they don't do "signed requests" to other servers (because they don't really have access to the private key in the first place).

      @marius

      In conversation about 5 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.