Integrating WordPress Reader and ActivityPub (Concept Mapping)

[Jiwoon-Kim]

Integrating WordPress Reader and ActivityPub (Concept Mapping)
First of all, WordPress Reader has site profiles and user profiles.
Basically, a profile also serves as a feed.

Site Profile
https://wordpress.com/reader/feeds/172271303

User Profile
https://wordpress.com/reader/users/kimjiwoon96

However, comments are separated from user profiles.
Comment
https://wordpress.com/reader/conversations

Subscriptions correspond to follows.
https://wordpress.com/reader/subscriptions

You can subscribe to subreddits, but they are RSS.
https://wordpress.com/discover/reddit

You can perform Like activities, but they are separated from the user profile. (In Misskey, you can configure whether to make your reaction list public.)
https://wordpress.com/activities/likes
https://www.w3.org/TR/activitypub/#liked
https://www.w3.org/TR/activitypub/#like-activity-outbox

Limitations
You cannot follow another user profile.
You cannot join a Fediverse forum (group actor).
In the Jetpack app, you can access the media library per site when writing a post. But is access to the media library even possible with only the basic ActivityPub specification?

An idea that should be looked at carefully is that the WordPress.com user profile acts like a multi-instance actor.
https://wordpress.com/reader/users/kimjiwoon96
If you look at the user profile, you can see posts written on multiple sites displayed in one feed.
It seems similar to how Lemmy’s person actor works.
Then, would it be better to pair the WordPress.com user profile with the main site’s person actor handle and treat WordPress websites as group actors?

Hmm… I think the blog profile, user profile, and forum profile (subreddit) are the most important functions that the WordPress Reader should implement, so wouldn’t it be better to distinguish actor types?

Hmm… for now, it seems better to separate the logic for handling posts and comments. The main instance where the user profile belongs can federate posts, but posting from other sites using the integrated handle seems difficult. However, federating comments under a single handle seems somewhat feasible.

---

Would it be possible to consider a WordPress website as a group actor?
That could depend on whether WordPress can adopt the mechanism of creating and publishing posts like Lemmy.
https://lemmy.world/create_post?communityId=114236

Example

1. Suppose the user is @[email protected],
   and subscribes to a community on another instance: [email protected].
2. lemmy.ml sends a Follow activity to the discuss.online server.
3. discuss.online sends an Accept response and approves.
4. After that, when a new post is made in [email protected],
   a Create(Note) activity is pushed to lemmy.ml.
5. lemmy.ml caches that post in the local DB,
   and displays it on the user’s timeline.

Personally, I still think that since a single Lemmy instance can have multiple forums, applying that to a WordPress blog (posts page) has more drawbacks.

WordPress has roles like subscriber, contributor, author, editor, and administrator, so I think simply implementing “only moderators can create posts” would be difficult.

---

Then how do you post to a remote forum in Lemmy?

Good question.
Posting to a remote forum in Lemmy is actually one of the core functions of the ActivityPub protocol —
that is, “subscribing to a community on another instance and posting to that community.”
It looks simple on the surface, but quite a complex federation process happens internally.
Let me explain step by step 👇

---

🌐 1. Prerequisite: Subscribing to a Remote Community (Follow)

First, to write a post in a remote community (e.g., [email protected]),
your instance (lemmy.ml) must follow that community.

Process

1. Your instance (lemmy.ml) queries the [email protected] community URI via ActivityPub (webfinger → actor)
2. lemmy.ml → sends a Follow Activity → to the discuss.online community actor
3. discuss.online → sends an Accept Activity → back to lemmy.ml
4. Now the lemmy.ml DB has the remote community cached locally

At this stage, the “remote community is registered in my instance.”
From then on, it can be used like a local community.

---

📝 2. Writing a Post to a Remote Community (Create Activity)

Now suppose the user inputs this on their instance UI:

Community: [email protected]: Decentralized AI architecturesBody: Exploring ActivityPub for federated neural nets...

Then, the post is temporarily stored in the local DB, and the following ActivityPub message is generated:

{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://lemmy.ml/activities/create/12345", "type": "Create", "actor": "https://lemmy.ml/u/jiwoon", "object": { "id": "https://lemmy.ml/post/12345", "type": "Note", "attributedTo": "https://lemmy.ml/u/jiwoon", "to": ["https://discuss.online/c/ai", "https://www.w3.org/ns/activitystreams#Public"], "content": "Exploring ActivityPub for federated neural nets...", "name": "Decentralized AI architectures" }}

And this Create Activity is sent via HTTP POST to https://discuss.online/inbox (the inbox of the community actor).

---

📨 3. Reception and Processing on the Remote Server

discuss.online receives this Create activity and performs the following:

1. Signature verification: confirms that the request from lemmy.ml is from a trusted instance (HTTP Signatures)
2. Validation: checks JSON-LD structure, permissions, spam
3. Post storage: records the post in the remote community DB (origin = lemmy.ml)
4. Announcement/Federation: rebroadcasts this post to [email protected]’s follower instances via Create

As a result,
on your instance (lemmy.ml) it appears as “my post,”
and on discuss.online it appears as “a post written by an external user,” but they stay fully synchronized.

---

💬 4. Comments (Replies) Work the Same Way

Comments (Comment) are also delivered as Create activities.
The difference is that the inReplyTo field points to the original post URL:

"inReplyTo": "https://discuss.online/post/98765"

This allows the “conversation tree” to be reconstructed across ActivityPub,
so both instances display the same comment thread.

---

🧭 5. Local vs Remote Distinction

Item	Local Post	Remote Post
Storage location	My instance DB (origin)	Cached copy (federated)
Edit permission	Full	Limited
Deletion (Delete)	Delete Activity → propagated	Follows origin server’s instruction
Voting (Like/Dislike)	Processed on my instance	Sent to remote server

---

⚙️ 6. Summary of Actual Operation

1️⃣ [email protected] Follow2️⃣ Accept3️⃣ Create(Post)4️⃣ Accept(Create)5️⃣ Federate to followers

So, “posting to another instance’s community”
👉 is ultimately handled perfectly through the ActivityPub Create → Accept → Distribute chain.

“Full Lemmy Remote Post Creation Sequence Diagram (actor → community → followers)”

---

Then, if I joined forum1 of instance A but not forum2, how do I allow posting permission only for a specific forum?

This is the key point where Lemmy’s permission–follow structure (ActivityPub + local permission system) intersects.
To understand it precisely, you first need to distinguish between “join (membership),” “follow,” and “write permission.”
These three may all look like “follow relationships” in ActivityPub, but Lemmy handles them differently.

---

🧩 1️⃣ Basic Premise: Every Community is an ActivityPub Actor

[email protected] → https://a.instance/c/[email protected] → https://a.instance/c/forum2

Each community (c/forum1, c/forum2) exists as an ActivityPub Group type actor
and manages its own inbox / outbox / followers / moderators / banned list.

---

⚙️ 2️⃣ Lemmy Internal Permission System

Lemmy manages additional role-based permissions in its DB beyond ActivityPub standards.

Permission Type	Description	ActivityPub Equivalent
member	User who joined the community (can post/comment)	Follow
follower	Just following, read/feed only	Follow
moderator	Community administrator	Add / Remove / Announce etc.
banned_user	Blocked user	Block

So even if you follow, posting (write) permission may not be granted.
This is determined separately in Lemmy’s DB, depending on whether you’re registered as a “member” after Accept(Follow).

---

🧭 3️⃣ How to Allow Posting Only in Certain Forums

✅ Method 1: Community Access Level Setting

When creating a community in Lemmy, you can choose one of the following:

Access Level	Description
Public	Anyone can read, follow, and post
Restricted	Readable, but posting/comments require moderator approval
Private	Only invited users can access
Local Only	Only users of that instance can post

→ For example, if [email protected] is Public,
and [email protected] is Private,
then from outside instance A, you can post in forum1 but not forum2.

---

✅ Method 2: “Join Required” Option

If you enable Require users to join before posting in the community settings (c/forum2/edit),
then you cannot post with a simple follow — you must press the “Join” button.

Internally, this sends:

{ "type": "Follow", "actor": "https://b.instance/u/jiwoon", "object": "https://a.instance/c/forum2"}

→ When a.instance receives this, it records you as member in the DB and returns an Accept response.
→ Only then will it allow Create activities.

So even though it’s still a “Follow” in ActivityPub,
Lemmy extends follow into membership internally and separates permissions.

---

✅ Method 3: Moderator Whitelist

If forum2 is Private,
the moderator must add a specific account (@[email protected]) to the whitelist.
In that case, there’s a manual approval step before Accept(Follow) —
just like approving followers in Mastodon.

---

💡 Example Scenario

Instance	Community	Access Level	Your Status	Result
a.instance	forum1	Public	Follow only	Can post
a.instance	forum2	Private + Join Required	Not followed	Cannot post
a.instance	forum2	Private + Join Required	Joined and approved	Can post

---

⚠️ Note

• “Follow” at the ActivityPub level may only function as feed subscription.
• “Join” is recorded in Lemmy’s DB as can_create = true,
  and must pass ACL (access control list) validation when processing Create.
• Therefore, the permission difference between two communities in instance A
  cannot be represented purely through ActivityPub standards —
  it’s handled by Lemmy’s application-level extended logic.

---

In summary 🔍

Follow = simple subscription,
Join = membership (includes write permission),
Moderator/Private settings = additional ACL control.

---

Sequence diagram (Follow → Accept → Join → Create → Reject flow)

---

The problem is that in the structure where the person writes and the group announces, you can post even without permission.

🧩 1️⃣ Basic Structure

In ActivityPub, Lemmy is modeled like this:

• Person → user’s Actor (type: Person)
• Community → forum’s Actor (type: Group)
• Posts are written by Person,
  and the Community announces (relays) them.

So the actual actor of the Create activity is the Person,
and the Group sees it and sends an Announce to its own timeline.

{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Create", "actor": "https://a.instance/u/kim", "object": { "type": "Note", "attributedTo": "https://a.instance/u/kim", "to": ["https://b.instance/c/forum1"] }}

Then b.instance’s forum1 announces like this:

{ "type": "Announce", "actor": "https://b.instance/c/forum1", "object": "https://a.instance/post/123"}

---

🔓 2️⃣ The Problem with This Structure

This structure leads to the “posting without permission” issue.
Because ActivityPub is decentralized,
anyone can send a Create activity from a remote server.

• kim from a.instance
• sends a Create activity to b.instance/c/forum2
• b.instance just checks “who is this?”
  and if the policy doesn’t block it, simply accepts it.

It’s similar to an email system —
“anyone can send mail, and the receiver must filter it.”

---

## 🧱 3️⃣ How Lemmy Blocks It Internally

So Lemmy doesn’t just operate at the ActivityPub protocol level,
it also has a separate verification logic at the application level.

When a user writes a post to a remote community
→ that instance checks the community’s mod log or membership record
→ verifies, “Is this person a member of this community?”
→ if not, it returns a Reject response.

In other words, Lemmy adds
an “application-level ACL” (access control layer)
on top of ActivityPub’s base freedom.

---

⚙️ 4️⃣ How to Allow “Posting Only in Specific Forums”?

It’s impossible within ActivityPub itself.
→ Because a Create activity has no structure like “this person is a member of this Group.”

Instead, it can be implemented at the application level like this:

Step	Description
1️⃣	Store lists such as member / moderator / banned in the Group Actor
2️⃣	Check whether the actor of the Create request received by the Group is included in this list
3️⃣	If not included, process as Reject or Ignore
4️⃣	If included, publish with Announce

In practice, Lemmy manages this through the LocalUser ↔ CommunityFollower relationship.
Therefore, “only members of a joined forum can post.”

---

💬 Conclusion

“The problem is that in a structure where a person writes a post and the group announces it, the person can just write without permission.”

Strictly speaking,
✅ “It can be sent, but it won’t be accepted.”
That is, technically “writing” is possible,
but unless the community “approves,” it won’t appear in the public feed.

---

How are categories implemented in an email inbox?

The inbox categories in an email system (e.g., Primary, Promotions, Social, Forums, Updates) are more than simple “folder classification.”
They are structures combining large-scale spam filters + ML classification systems + user-defined rules.
Let’s break them down one by one.

---

📬 1️⃣ Basic Structure: “Mail = Object, Inbox = Index”

The core data structure of an email system is as follows:

User ├── Inbox (Mail index) │ ├── message_id_1 → metadata │ ├── message_id_2 → metadata │ └── ... ├── Sent ├── Trash └── Labels / Categories

The mail body (message) is essentially an independent object (message/rfc822).

Inbox, folder, category are sets of metadata indexes pointing to that message.
That is, in reality, “moving mail” is just changing its position or tag within the index.

---

🧱 2️⃣ Three Implementation Methods for Categories

(1) Folder-based structure (IMAP-based)

Older Outlook, Yahoo Mail, and most standard mail clients use this structure.

The IMAP protocol manages folders through commands like LIST, SELECT, and MOVE.

Categories such as “Social” or “Promotions” are essentially implemented as IMAP folders:

INBOX/├── Promotions/├── Social/├── Updates/

📎 Downside: A single mail can belong to only one folder.
So Gmail extended this.

---

(2) Label-based Structure (Gmail Style)

Gmail extended IMAP to implement it using labels instead of folders.

• Example:

    { "id": "msg_123", "labels": ["INBOX", "SOCIAL"], "from": "[email protected]", "subject": "You have new notifications"}
  

• A single mail can have multiple labels.
  → The same message can appear simultaneously in “Inbox” and “Social.”

This is actually similar to ActivityPub’s “Collection” structure:
Inbox is an OrderedCollection,
and Label acts like a subview filter of that collection.

---

(3) Virtual Categories (ML + Tag-based Filter)

Modern systems like Gmail, Outlook, and Naver use this.
There are no actual “category folders”;
messages are virtually labeled through ML classification of metadata.

Examples of classification criteria:

Category	Characteristic signals
Social	from domain is SNS (facebookmail.com, twitter.com, etc.)
Promotions	Contains lots of HTML + images, has unsubscribe header
Updates	Keywords related to order, payment, or delivery
Forums	Mail headers include List-Id, Precedence: list, etc.

That is, the ML classifier learns patterns from tens of millions of messages,
and performs real-time classification at reception time,
adding a category tag to the mail header.

---

🧩 3️⃣ Actual Storage Model (e.g., Gmail Internal Structure)

Taking Gmail as an example,
mail storage is based on Bigtable,
and each message has fields like this:

Field name	Description
msg_id	Unique identifier
thread_id	Conversation thread ID
from, to, subject, date	Header
body_snippet	Indexed body summary
labels[]	System/user labels
category	ML category (social, promotions, etc.)
spam_score	Spam score
importance_score	Importance (Inbox Priority)

In the user UI it appears as “folders,” but in reality, it’s a label filter query.

SELECT * FROM messagesWHERE user_id = 'kimjiwoon'AND labels CONTAINS 'INBOX'AND category = 'SOCIAL';

---

⚙️ 4️⃣ From the ActivityPub Perspective?

The email inbox category structure
has much in common with ActivityPub’s Inbox / Outbox concept.

Email Structure	Corresponding ActivityPub Concept
Inbox	actor’s inbox collection
Sent / Outbox	actor’s outbox
Label / Category	Collection Filter (custom vocabulary)
Spam / Trash	filtered collections or reject rules
Rules	server policy / filtering actor

If you want to implement “Inbox categories” in an ActivityPub-based social app,
you can configure “sub-collections” per label for the OrderedCollection:

{ "id": "https://example.com/users/kim/inbox?filter=social", "type": "OrderedCollection", "name": "Social", "filter": { "object.type": ["Note"], "actor.domain": ["mastodon.social", "bsky.app"] }}

That is, in ActivityPub, Inbox categories can also be implemented as “query-based virtual collections.”

---

🧠 Summary

Concept	Description	Implementation Method
📂 Folder type	IMAP standard folder sort	Static
🏷️ Label type	Multi-labeling in Gmail	Multi-tagging
🤖 ML type	Automatic categorization	Content-based sorting
🌐 ActivityPub type	Inbox subview / filter	Query-based collection

---

“Design structure for categorizing ActivityPub inbox like an email (e.g., social / system / mentions / dms)”

[Jiwoon-Kim]

#2325 (comment)