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
    Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 02:52:46 JST Hrefna (DHC) Hrefna (DHC)

    Some theorycrafting for a social network that is _like_ AP-derived systems, but is not based on AP.

    First, some premises:

    1. I am following a traditional actor pattern here. When I say "actor" I do not mean "AP actor" but rather an object with an inbox and a name that has some black box mechanism behind it.

    2. I am _not_ discussing security or half a dozen other things that would be vitally important for a full proposal.

    3. I am very, very rarely going to be discussing payload.

    1/

    In conversation 6 months ago from hachyderm.io permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 02:56:38 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      First, let's define a _message layer_. Here we have a concept of an _actor reference_.

      An actor reference has:

      1. An inbox.
      2. A URI id that just returns this reference object.
      3. A structured type field, indicating what class of messages it takes and some basic behaviors around it. This can be simple or relatively complex

      These are functionally immutable references. A _user_ is a distinct concept and may change actors around at any point. They can also refer to a central actor via DNS

      2/

      In conversation 6 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:00:18 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      _Messages_ are ephemeral, immutable objects that contain the following information:

      1. An incrementing id that is unique per server.
      2. A server.
      3. A URI for the _payload being referred to_.
      4. A type.
      5. Any routing information.

      So I could say:

      Create {
      id: <uuidv7>
      server: <uri>
      canonical_uri: <uri>
      from: <originating user>
      to: [<list of users>]
      }

      That's it. No payload. There are other fields that may be interesting here, but we're being a bit minimalist.

      3/

      In conversation 6 months ago permalink

      Attachments


    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:02:52 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      Now when someone goes to the server's canonical URI you'll get a full AS2 object (or whatever) in some normalized form. The details don't matter so long as the canonical_uri matches the id.

      So you can see how this starts to develop:

      Alice sends Bob a message saying that she created a Note (1).
      Alice sends Bob a message saying that she created a Note (2).
      Alice sends Bob a message saying that she created a Note (3).
      Alice sends Bob a message saying that she updated a Note (1).

      4/

      In conversation 6 months ago permalink

      Attachments


    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:04:49 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      So now we have a message passing system and an actor reference. Cool.

      But what does a user look like? How about a server? What about these payloads?

      Well. For that we need a _data layer_.

      5/

      In conversation 6 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:07:44 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      The data layer is responsible for serving the payloads of objects.

      We _could_ have Bob go to alice and systematically call each message in a row, but that's a waste of time and energy.

      Better would be to provide a single endpoint on the server where I can say "give me all objects from Alice that were sent to Bob or are marked as:Public starting with id <foo>"

      This may be attached to Alice directly but it doesn't have to be: it could be a generic per-server endpoint.

      6/

      In conversation 6 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:12:05 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      (nb. I am cheating a bit with terminology, technically this would be a _service layer_ not a data layer, but data layer is cleaner for what we're talking about and I don't want confusion with the message layer).

      The core here is that this is a single, paginated request that fetches _objects_ or _payloads_. The type can be content negotiated with HTTP, it can use different wire formats, all of that is less important.

      7/

      In conversation 6 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:15:52 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      Now what about the user?

      Users do not exist in the message layer. They _are not actors_.

      Rather they _contain_ actors.

      You get the user information from anything. DNS, a credentials server, I don't care about that for right now, but it has on there an inbox object, or maybe multiple named inbox objects, and they have actor _references_ (see above) that you can now send messages to.

      8/

      In conversation 6 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:17:46 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      Now it does not matter if the same actor serves multiple users, or multiple inboxes for a user, or whatever else. It does not matter if they are all distinct actors that then forward their information to a central actor that then fans them out to other servers entirely.

      What matters is that you fetch the user object from a canonical store and it tells you where the actors live and information like how to fetch posts from this person.

      9/

      In conversation 6 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:19:32 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      One could also envision a series of redirects.

      My information is stored on server <foo> but all of my canonical ids reference hrefna.dev/whatever.

      Why? Because I'm proxying the calls over to a backend server that I reserve the right to change in the future.

      There are a thousand things you can do from here, but basically we now have a basic lightweight framework for a scalable, message-passing-based social network.

      10/10

      In conversation 6 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.

Embed this notice