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
    Rich Felker (dalias@hachyderm.io)'s status on Sunday, 13-Jul-2025 12:26:47 JST Rich Felker Rich Felker
    • Jenniferplusplus

    @jenniferplusplus @hipsterelectron Mechanically, "rejecting a reply" is just refusal to include it when a request for the replies/thread is made, pretending it's not there.

    If you do that, only users whose home instance is the same instance as the unwanted reply-guy is replying from might be able to see the reply.

    Adding something to the protocol to ask that instance not to allow it is the main addition that would be nice.

    In conversation about 10 months ago from hachyderm.io permalink
    • Embed this notice
      Jenniferplusplus (jenniferplusplus@hachyderm.io)'s status on Sunday, 13-Jul-2025 12:42:19 JST Jenniferplusplus Jenniferplusplus
      in reply to

      @dalias @hipsterelectron the de facto definition of a reply is any post that sets a value for the inReplyTo field, and the set of instances that can see it is any instance that received it, plus the few that might later request it.

      Whether it gets added to a replies collection is basically never a factor.

      It's also relevant that there is no way to query a collection. All you can do is iterate it. So the only way to confirm an objects presence or absence in a collection is to iterate the whole thing. Which contributes to the wild west authorization.

      In conversation about 10 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Sunday, 13-Jul-2025 12:48:02 JST Rich Felker Rich Felker
      in reply to
      • Jenniferplusplus

      @jenniferplusplus @hipsterelectron I don't know the exact protocol mechanism, but there's some iterator by which you obtain all replies to a post, or similar, from the instance the post is from.

      All that instance has to do is omit the offending post from the iteration, and nobody will see it as part of the thread except possibly on the instance it originated from.

      In conversation about 10 months ago permalink
    • Embed this notice
      Jenniferplusplus (jenniferplusplus@hachyderm.io)'s status on Sunday, 13-Jul-2025 12:51:57 JST Jenniferplusplus Jenniferplusplus
      in reply to

      @dalias @hipsterelectron right. What I'm telling you is nobody does it that way, because it's a performance nightmare.

      In conversation about 10 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Sunday, 13-Jul-2025 13:23:27 JST Rich Felker Rich Felker
      in reply to
      • Jenniferplusplus

      @jenniferplusplus @hipsterelectron Don't they omit blocked accounts from the iteration though? If so, how is this harder?

      In conversation about 10 months ago permalink
    • Embed this notice
      Jenniferplusplus (jenniferplusplus@hachyderm.io)'s status on Sunday, 13-Jul-2025 14:11:42 JST Jenniferplusplus Jenniferplusplus
      in reply to

      @dalias @hipsterelectron 3rd party servers don't constantly re-iterate reply collections every time they encounter a post that claims to be a part of one. Because it would take forever, and it would produce an enormous traffic amplification attack on every participant in the network.

      In conversation about 10 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.