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
    me (me@social.jlamothe.net)'s status on Saturday, 06-Jun-2026 10:03:36 JST me me
    • Evan Prodromou
    @evan Yes, but... it would be pretty difficult to enforce that, for the same reasons that DRM is a fundamentally flawed idea.
    In conversation about a day ago from social.jlamothe.net permalink
    • Embed this notice
      Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 06-Jun-2026 10:03:34 JST Evan Prodromou Evan Prodromou
      in reply to

      @me no, it's not that hard at all. Currently the relay interface sends "fat pings" -- it includes the full content object. If it instead used "thin pings", with just the URL of the content, the relay and all the downstream servers have to fetch the content from the source server. That lets the source server enforce server blocks, including user server blocks.

      In conversation about a day ago permalink
    • Embed this notice
      Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 06-Jun-2026 10:03:50 JST Evan Prodromou Evan Prodromou
      in reply to

      @me of course, if the user opted out of being relayed, the source server could simply not send their content. Problem solved.

      In conversation about a day ago permalink
    • Embed this notice
      Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 06-Jun-2026 12:43:43 JST Evan Prodromou Evan Prodromou
      in reply to

      @me no, you're absolutely right. Once the content is delivered to a remote server, it's hard to force it to do the right thing.

      It's one of the reasons we're doing e2ee messaging.

      https://github.com/swicg/activitypub-e2ee/

      In conversation about 21 hours ago permalink

      Attachments


      1. Domain not in remote thumbnail source whitelist: opengraph.githubassets.com
        GitHub - swicg/activitypub-e2ee: Coordination of work on end-to-end encryption with ActivityPub
        Coordination of work on end-to-end encryption with ActivityPub - swicg/activitypub-e2ee
    • Embed this notice
      me (me@social.jlamothe.net)'s status on Saturday, 06-Jun-2026 12:43:45 JST me me
      in reply to
      • Evan Prodromou

      @evan To be honest, I haven't looked that deeply into the protocol. I'm sure what you're telling me is true. After all, you literally wrote the book on ActivityPub. Also, this is perhaps not exactly what you're talking about, but as soon as a post federates to another server (because the poster has a legit follower there) the originating server is no longer in exclusive control of the content of that post, is it not?

      Unless I'm fundamentally misunderstanding something here—which I'll admit is a possibility—a single misbehaving server could circumvent this entire system, could it not? Obviously, there's the option of defederating such a server, but you'd have to know it's happening first. It's not just about trusting your own server, but also every server you federate your posts to.

      Am I way off base here? If so, I'd love to understand how.

      In conversation about 21 hours ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: market.name.am
        to.am is for sale!

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.