Commit 97dc2a0f authored by Alex Castaño's avatar Alex Castaño

More docs about architecture and ActivityPub

parent 897a0792
Pipeline #39472434 passed with stages
in 7 minutes and 40 seconds
# Alex' Thoughts 05/10/18
## Pleroma.Web.ActivityPub
This could be a completely independent library.
Maybe it is a good idea to keep separate ActivityStream (vocabulary and schemas) from ActivityPub (protocol and notifications).
I don't know if schema `Notification` should live in any library.
Specs talk about notifications but it isn't an object or something similar.
### Inbox & Outbox current implementation
I thought it could be like "InboxItem" in FunkWhale implementation: http://docs-funkwhale-funkwhale-549-music-federation-documentation.preview.funkwhale.audio/federation/index.html#activity-creation-and-delivery
`InboxItem` table could be a really good idea.
`Inbox` is a term very clear and specific in the ActivityPub specification,
and furthermore, it would be possible to implement an generic "Inbox" get.
However, it seems we don't implement `Inbox` external `get`s or "Outbox" internal `post`s: https://www.w3.org/TR/activitypub/#Overview
Checking how a message is sent from external server to an actor's `Inbox` I discovered we only support:
* `Create` Activity types for
* `Article`, `Note` & `Video` Object type
* `Follow` Activity type.
* `Accept` (follows?)
* `Reject` (follows?)
* `Like`
* `Announce`
* `Update`
* `Person`, `Application`, `Service`, `Organization`
* `Delete`
* `Undo`
* `Announce`, `Follow`, `Block`, `Like`
* `Block`
We'll have to implement all of them.
This is going to be really hard to make generic or to add hooks to the possible specific application.
Secondly, reading the actor's `Outbox` it seems we are not sending the actor's activity,
we are sending actor's profile:
* summary
* name
* following list
* etc
ActivityPub specs says:
>>>
The outbox is discovered through the outbox property of an actor's profile. The outbox MUST be an OrderedCollection.
The outbox stream contains activities the user has published, subject to the ability of the requestor to retrieve the activity (that is, the contents of the outbox are filtered by the permissions of the person reading it). If a user submits a request without Authorization the server should respond with all of the Public posts. This could potentially be all relevant objects published by the user, though the number of available items is left to the discretion of those implementing and deploying the server.
The outbox accepts HTTP POST requests, with behaviour described in Client to Server Interactions.
>>>
So this has to be fixed.
I still don't know if `Notification` in our code would be similar to `InboxItem`,
but a good idea at least for ActivityPub library.
### Pleroma.Web.ActivityPub.Transmogrifier
The code around the `Inbox` implementation is in this module.
I didn't know what this module does but it has a little bit of doc:
> A module to handle coding from internal to wire ActivityPub and back.
It has difficult to understand function names like `fix_object` which doc says:
> Modifies an incoming AP object (mastodon format) to our internal format.
We have to split this module better.
For a generic library we should have any code related to Mastodon or any other app.
Of course, it is going to be very useful to have a mapper from external to internal data.
We have to find a better name.
# Alex' Thoughts 04/10/18
## Applications and Libraries
What is a Elixir/Erlang application, from elixir docs https://hexdocs.pm/elixir/Application.html:
> Applications are the idiomatic way to package software in Erlang/OTP. To get the idea, they are similar to the “library” concept common in other programming languages, but with some additional characteristics.
An application is a component implementing some specific functionality, with a standardized directory structure, configuration, and lifecycle. Applications are loaded, started, and stopped.
>>>
Applications are the idiomatic way to package software in Erlang/OTP. To get the idea, they are similar to the “library” concept common in other programming languages, but with some additional characteristics.
An application is a component implementing some specific functionality, with a standardized directory structure, configuration, and lifecycle. Applications are loaded, started, and stopped.
>>>
We currently have only a single application, Pleroma.
I don't think we need more in the short or medium term.
......
......@@ -10,7 +10,6 @@ config :pleroma, ecto_repos: [Pleroma.Repo]
config :pleroma, Pleroma.Repo, types: Pleroma.PostgresTypes, adapter: Ecto.Adapters.Postgres
config :pleroma, Pleroma.Upload,
uploader: Pleroma.Uploaders.Local,
strip_exif: false
......
......@@ -10,7 +10,7 @@ defmodule Mix.Tasks.GenerateInviteToken do
IO.puts(
"Url: #{
Pleroma.Web.Endpoint.url() <> "/register?" <> URI.encode_query("invite": token.token)
Pleroma.Web.Endpoint.url() <> "/register?" <> URI.encode_query(invite: token.token)
}"
)
else
......
......@@ -89,6 +89,7 @@ defmodule Pleroma.Activity do
create_activity_by_object_id_query([ap_id])
|> Repo.one()
end
# just matching everything to return nil seems a shortcut
def get_create_activity_by_object_ap_id(_), do: nil
......
......@@ -31,7 +31,7 @@ defmodule Pleroma.UserInviteToken do
Repo.insert(token)
end
#Create a `Ecto.Changeset` to set `Pleroma.UserInviteToken` as used.
# Create a `Ecto.Changeset` to set `Pleroma.UserInviteToken` as used.
def used_changeset(struct) do
struct
|> cast(%{}, [])
......
......@@ -11,6 +11,8 @@ defmodule Pleroma.Web.ActivityPub.UserView do
# the instance itself is not a Person, but instead an Application
def render("user.json", %{user: %{nickname: nil} = user}) do
# This is already done outbox controller?
# This logic should not behere
{:ok, user} = WebFinger.ensure_keys_present(user)
{:ok, _, public_key} = Salmon.keys_from_pem(user.info["keys"])
public_key = :public_key.pem_entry_encode(:SubjectPublicKeyInfo, public_key)
......
......@@ -1199,7 +1199,8 @@ defmodule Pleroma.Web.MastodonAPI.MastodonAPIController do
def register_post(conn, %{"register" => register}) do
with {:ok, user} <- TwitterAPI.register_user(register),
{:ok, app} <- get_or_make_app(),
{:ok, auth} <- Authorization.create_authorization(app, user), # init as new logged in user
# init as new logged in user
{:ok, auth} <- Authorization.create_authorization(app, user),
{:ok, token} <- Token.exchange_token(app, auth) do
conn
|> put_session(:oauth_token, token.token)
......
......@@ -403,7 +403,6 @@ defmodule Pleroma.Web.Router do
get("/:sig/:url", MediaProxyController, :remote)
end
scope "/", Fallback do
get("/registration/:token", RedirectController, :registration_page)
get("/*path", RedirectController, :redirector)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment