Hollo :hollo:

:hollo: A federated single-user microblogging software.

Public Key

npub1y3p3f3xld8ex2y6a5v6xqlgzwkua24ff7erqlx6vhyync6jfztqsyvujen

NIP-05 Address

hollo@hollo-social.mostr.pub

Profile Code

nprofile1qqszgsc5cn0knun9zdw6xdrq05p8tww4255lv3s0ndxtjzfudfy39sgpz4mhxue69uhhyetvv9ujuerfw36x7tnsw43qzrthwden5te0dehhxtnvdakqpfxgwk

Publishing to

relay.ditto.pub

nos.lol

nostr.wine

Author Public Key

npub1y3p3f3xld8ex2y6a5v6xqlgzwkua24ff7erqlx6vhyync6jfztqsyvujen

Show more details

Last Notes

2026-10-26 23:51:49 UTC

Hollo security updates: 0.8.17 and 0.9.25
If you run Hollo, update to 0.8.17 or 0.9.25 now. These releases fix GHSA-r48c-xx2h-fv4g, a DNS rebinding vulnerability in Fedify that could bypass Hollo's server-side request forgery (SSRF) protection and cause requests to reach internal services.
Fedify checked that a hostname resolved only to public addresses, then let the HTTP client resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection. Redirects and alternate-document links had the same gap.
The affected Fedify paths used by Hollo include remote document loading (authenticated or not), outbound activity delivery, and WebFinger lookups. On Node.js, which Hollo uses, the fix restricts connections to addresses that passed validation. Hollo's ALLOW_PRIVATE_ADDRESS=true option still permits private destinations; leave it unset for public federation. For full technical details, see the Fedify security announcement and the advisory linked above.
All releases on the supported Hollo 0.8.x and 0.9.x lines up to and including 0.8.16 and 0.9.24 are affected. 0.8.17 and 0.9.25 are the first fixed releases and the latest on those lines, incorporating Fedify 2.1.31 and 2.2.20 respectively. Hollo 0.7.x and earlier are no longer supported under the Hollo security policy; operators on those lines should move to a supported release.
For 0.8.x deployments, update to 0.8.17:
docker pull ghcr.io/fedify-dev/hollo:0.8.17
For 0.9.x deployments, update to 0.9.25:
docker pull ghcr.io/fedify-dev/hollo:0.9.25
After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile using the pnpm version pinned in that tag's package.json, run pnpm run build, and restart the server.
If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during the new version's automatic migration.
Thanks to @nprofile…j5qe for reporting the DNS rebinding issue to the Fedify project.
If anything is unclear, ask below.

2026-10-17 09:41:05 UTC

Hollo security updates: 0.8.16 and 0.9.24
If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.
For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.
For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.
For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.
For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.
Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.
The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.
The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.
For 0.8.x deployments, update to 0.8.16:
docker pull ghcr.io/fedify-dev/hollo:0.8.16
For 0.9.x deployments, update to 0.9.24:
docker pull ghcr.io/fedify-dev/hollo:0.9.24
After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.
If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.
Thanks to Yami Odymel (@nprofile…eh5f) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@nprofile…almw) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.
If anything is unclear, ask below.

2026-09-27 10:26:15 UTC

Hollo security updates: 0.8.12 and 0.9.19
If you run Hollo, update to a patched release now. Fedify has disclosed three vulnerabilities that affect Hollo: CVE-2026-96625, a critical actor impersonation vulnerability; CVE-2026-96623, a high-severity denial-of-service vulnerability in remote document parsing; and CVE-2026-96624, a medium-severity server-side request forgery vulnerability in outbound activity delivery. Treat the actor impersonation issue as an immediate upgrade: anyone on the internet could have an activity accepted by your Hollo inbox as coming from any actor.
For CVE-2026-96625, Fedify verified the signature on an incoming activity, but trusted the signing key document's own claim about whom the key belonged to. An attacker with an ordinary HTTP server could serve a key document naming any actor as its owner and have activities accepted under that actor's identity. No account on the receiving Hollo instance was required. The same flaw affected signed-key ownership checks used to restrict access to posts, allowing a forged key document to pass those checks under another actor's identity.
The fix resolves the claimed owner's actor document and requires it to link back to the key. It also validates the origin of fetched actor documents. Fedify's built-in key cache automatically stops reading entries whose ownership had not been verified, so Hollo operators do not need to clear that cache manually.
For CVE-2026-96623, Fedify parsed JSON bodies without a byte limit, including inbox bodies and remote documents such as keys, actors, objects, JSON-LD contexts, WebFinger descriptors, and NodeInfo documents. An attacker could exhaust memory and CPU with a large body, including a compressed response that expanded substantially before parsing. An inbound body limit at a reverse proxy did not protect the outbound fetch paths.
The fix limits JSON bodies to 16 MiB after decompression. Oversized inbox requests receive HTTP 413, and remote JSON documents larger than this limit are rejected.
For CVE-2026-96624, outbound activity delivery validated neither the inbox URL advertised by a remote actor nor its redirect destinations. A remote actor could point its inbox at a loopback address, a link-local cloud metadata service, or a private network host, or redirect delivery there. On the RSA delivery path, the redirected request remained a POST carrying the activity body and was re-signed for the internal host.
The fix validates the initial destination and every redirect target before sending a request. This is a separate path from the authenticated document loader fixed in the previous Hollo security update. Hollo's existing ALLOW_PRIVATE_ADDRESS=true option still permits private destinations, including private inbox URLs and redirect targets. Use it only in test environments or closed federations where you control the remote actors.
For full technical details, see the Fedify security advisories for CVE-2026-96625, CVE-2026-96623, and CVE-2026-96624, and the Fedify security announcement.
All Hollo versions in the supported 0.8.x and 0.9.x release lines up to and including 0.8.11 and 0.9.18 are affected. Patched releases are 0.8.12 for the 0.8.x series and 0.9.19 for the 0.9.x series, incorporating Fedify 2.1.24 and 2.2.13 respectively.
Hollo 0.7.x is also affected. It and earlier release lines are no longer supported under the Hollo security policy. Upgrade to a supported release series rather than remaining on an older version.
For 0.8.x deployments, update to 0.8.12:
docker pull ghcr.io/fedify-dev/hollo:0.8.12
For 0.9.x deployments, update to 0.9.19:
docker pull ghcr.io/fedify-dev/hollo:0.9.19
After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.
Thanks to @kaimandalic and @nprofile…tuzh for independently reporting the actor impersonation issue, to @kaimandalic for reporting the unbounded document parsing issue, and to @euriconicacio for reporting the outbound delivery SSRF issue, and to all three for their responsible disclosure to the Fedify project.
If anything is unclear, ask below.

2026-08-26 12:19:01 UTC

Hollo security updates: 0.8.11 and 0.9.14
If you run Hollo, update to a current patched release now. Fedify has disclosed two vulnerabilities, one of which affects Hollo: CVE-2026-77632, a high-severity server-side request forgery vulnerability in Fedify's authenticated document loader.
Hollo relies on the authenticated document loader when it fetches remote documents such as actors and public keys with a signed HTTP request. Affected Fedify versions checked that the initial URL resolved to a public network destination, but did not apply the same check when that URL returned an HTTP redirect. An attacker who controlled the public URL could therefore redirect the signed request to a loopback address, a link-local cloud metadata service, or an RFC 1918 private address.
An unauthenticated attacker could reach this path by sending an inbox request with a signature whose keyId points to an attacker-controlled public URL. Fedify has to fetch the key before it can verify the signature, so even a bogus signature is enough to trigger the request. The demonstrated attack is blind SSRF: the internal response is consumed while resolving the remote document and is not automatically returned to the attacker.
The fix validates every redirect target before fetching it. Hollo's existing ALLOW_PRIVATE_ADDRESS option still permits private destinations when an operator explicitly opts in, such as for a closed federation or test environment.
The other disclosed vulnerability, CVE-2026-69132, concerns unbounded circuit-breaker state in Fedify 2.3.0 through 2.3.4. Hollo's supported 0.8.x and 0.9.x release lines use Fedify 2.1.x and 2.2.x respectively, so this issue does not affect them.
For full technical details, see the Fedify security advisories for CVE-2026-77632 and CVE-2026-69132, and the Fedify security announcement.
All Hollo versions in the supported 0.8.x and 0.9.x release lines up to and including 0.8.9 and 0.9.12 are affected by CVE-2026-77632. The fix first appeared in 0.8.10 for the 0.8.x series and 0.9.13 for the 0.9.x series. The current releases are 0.8.11 and 0.9.14, and those are the versions we recommend installing.
Hollo 0.7.x is also affected. It and earlier release lines are no longer supported under the Hollo security policy. Upgrade to a supported release series rather than remaining on an older version.
For 0.8.x deployments, update to 0.8.11:
docker pull ghcr.io/fedify-dev/hollo:0.8.11
For 0.9.x deployments, update to 0.9.14:
docker pull ghcr.io/fedify-dev/hollo:0.9.14
After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.
Thanks to Jace for reporting CVE-2026-77632 and to @nprofile…yhdd for reporting CVE-2026-69132, and for their responsible disclosure to the Fedify project.
If anything is unclear, ask below.

2026-05-20 17:39:43 UTC

Hollo security updates: 0.7.17, 0.8.6, and 0.9.1
If you run Hollo, update to a patched release now. CVE-2026-42462 affects Fedify's Linked Data Signature handling, and Hollo depends on Fedify for ActivityPub federation.
Fedify verifies incoming ActivityPub activities with several mechanisms, including HTTP Signatures, Object Integrity Proofs, and Linked Data Signatures. The vulnerable path is Linked Data Signatures: the signature is checked over the canonical RDF graph, but JSON-LD can represent the same graph in more than one JSON shape. In affected versions, that gap could let a signed activity be reshaped so that Fedify reads a different ActivityPub object shape than intended—without invalidating the signature.
The fix makes Fedify normalize Linked Data Signature-verified activities against its local JSON-LD context before interpreting them, and rejects JSON-LD constructs that can preserve the signed RDF graph while changing the ActivityPub object shape. For full technical details of the underlying vulnerability, see the Fedify security announcement.
All Hollo versions up to and including 0.7.16, 0.8.5, and 0.9.0 are affected. Patched releases are 0.7.17 for the 0.7.x series, 0.8.6 for the 0.8.x series, and 0.9.1 for the 0.9.x series.
For 0.7.x deployments, update to 0.7.17:
docker pull ghcr.io/fedify-dev/hollo:0.7.17
For 0.8.x deployments, update to 0.8.6:
docker pull ghcr.io/fedify-dev/hollo:0.8.6
For 0.9.x deployments, update to 0.9.1:
docker pull ghcr.io/fedify-dev/hollo:0.9.1
After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.
Thanks to @nprofile…c80l for the report and responsible disclosure to the Fedify project.
If anything is unclear, ask below.

2026-05-19 03:00:52 UTC

Hollo security updates: 0.7.16 and 0.8.5
If you run Hollo, update to a patched release now. Hollo 0.7.16 and 0.8.5 fix several security issues in ActivityPub federation, the web admin UI, OAuth, and the transitive fast-xml-parser dependency.
On the federation side, three inbox handlers were missing authorization checks. Any remote actor could send a Delete to remove any cached post by IRI, an Update to overwrite or first-materialize a cached post under another actor's name, or a cross-origin Announce whose attacker-controlled embedded body materialized as someone else's post. The checks now differ by activity type. A Delete is ignored unless the deleter's origin matches the cached post author's origin. An Update is ignored unless the activity actor, the embedded object's id, and its attributedTo all share an origin. For Announce, Hollo no longer trusts attacker-supplied embedded content to create or overwrite the original post: unknown cross-origin objects are fetched from their canonical URL, and any newly cached object must have matching id and attributedTo origins. Separately, Follow, Like, EmojiReact, and Announce from a blocked actor were processed normally and still produced notifications; they are now silently dropped at the inbox.
On the web admin side, login and OTP cookies were set without HttpOnly, SameSite, or Secure, and state-changing forms had no Origin or Sec-Fetch-Site check. A single reflected XSS could exfiltrate the admin session, and a malicious page could submit a hidden cross-site form to disable 2FA, delete an account, or silently authorize a rogue OAuth application. The affected dashboard routes and POST /oauth/authorize now run Hono's CSRF middleware, and the login and OTP cookies now carry those attributes.
The transitive fast-xml-parser (carried in via the AWS SDK that backs S3 storage) is now pinned to patched versions, closing one critical and several high-severity advisories. Hollo also now uses constant-time comparison for the OAuth PKCE check and the multi-credential client-secret consistency check, and it warns at startup when LOG_QUERY=true is set, because drizzle-orm logs bound parameter values, including OAuth tokens and other secrets.
All Hollo versions up to and including 0.7.15 and 0.8.4 are affected. Patched releases are 0.7.16 for the 0.7.x series and 0.8.5 for the 0.8.x series. CHANGES.md has the longer notes, including the availability trade-off for cross-origin Announce validation when the canonical origin is unreachable.
For 0.7.x deployments, update to 0.7.16:
docker pull ghcr.io/fedify-dev/hollo:0.7.16
For 0.8.x deployments, update to 0.8.5:
docker pull ghcr.io/fedify-dev/hollo:0.8.5
After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.
If anything is unclear, ask below.

2026-05-10 14:42:19 UTC

Hollo security updates: 0.7.15 and 0.8.3
If you run Hollo, update to a patched release now. A private network protection bypass in Fedify, the ActivityPub framework Hollo depends on, affects remote document loading. URLs with private IPv4 addresses encoded as IPv4-mapped IPv6 literals, such as http://[::ffff:7f00:1]/, could pass URL validation even though they refer to private or loopback addresses.
Hollo uses Fedify to fetch remote ActivityPub documents and related resources. An attacker who can make your Hollo instance fetch an attacker-controlled URL may be able to bypass the private address checks that are intended to reduce SSRF (Server-Side Request Forgery) risk.
All Hollo versions up to and including 0.7.14 and 0.8.2 are affected. Patched releases are 0.7.15 for the 0.7.x series and 0.8.3 for the 0.8.x series. For full technical details of the underlying vulnerability, see the Fedify security announcement.
For 0.7.x deployments, update to 0.7.15:
docker pull ghcr.io/fedify-dev/hollo:0.7.15
For 0.8.x deployments, update to 0.8.3:
docker pull ghcr.io/fedify-dev/hollo:0.8.3
After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.
Thanks to Changkyun Kim (@nprofile…jfsp) for the report and responsible disclosure to the Fedify project.
If anything is unclear, ask below.

2025-10-03 15:27:30 UTC

Security update: Hollo 0.6.12 is now available
We've released #Hollo 0.6.12 to fix a critical privacy #vulnerability where direct messages were being exposed in the replies section of public posts. Please update your instances immediately to ensure your private conversations remain private.
#security

2025-04-29 23:54:40 UTC

We're pleased to announce that #Hollo has been included in the Nivenly Fediverse Security Fund program!
The @nprofile…6qvx Foundation has launched a security bounty fund to support contributors who identify and help fix #security vulnerabilities in popular #fediverse software. Both Hollo and @nprofile…j979 are among the selected projects that meet their responsible security disclosure requirements.
This program will run from April–September 2025, with bounties of $250–$500 USD for high and critical security vulnerabilities.
We're honored to be recognized alongside other established fediverse projects like Mastodon, Misskey, and Lemmy. This further encourages our commitment to maintaining strong security practices.
If you're interested in contributing to Hollo's security, please follow our responsible disclosure process outlined in our SECURITY.md file.
Learn more about the program:
https://nivenly.org/blog/2025/04/01/nivenly-fediverse-security-fund/

2025-03-23 14:23:12 UTC

Security Update: Hollo v0.3.10, v0.4.11, v0.5.5 Released
We've released security patches for Hollo in versions v0.3.10, v0.4.11, and v0.5.5.
These updates address important security vulnerabilities, and we strongly recommend all users update immediately.
Docker users can update with:
docker pull ghcr.io/fedify-dev/hollo:0.5.5
# Or your current version series: 0.4.11, 0.3.10
For manual installations:
git fetch
git checkout 0.5.5 # Or 0.4.11, 0.3.10
pnpm install
For complete installation instructions, please visit our docs.
Thank you for using Hollo and helping keep our community secure.

2024-12-31 17:08:00 UTC

Have you been having trouble fetching accounts or posts from #Akkoma that have custom emojis in #Hollo?
This is because they represent an Emoji object as an invalid JSON-LD object. Fortunately, this patch fixes that issue, so keep an eye out for it.
https://hollo.social/@fedify/01941dab-e4c3-7ce0-9307-b5b8c095d521
#nevent1q…mc03

2024-12-31 04:21:23 UTC

Did you know? #Hollo supports #Misskey/#Pleroma-style #quotes. You can quote another post by adding a link to it. If a post contains any link to an #ActivityPub object of Article/Note/Question, Hollo quotes it in the post.

2024-12-01 05:40:07 UTC

- reply

Hollo 0.3.0이 릴리스되었습니다! Hollo는 ActivityPub을 지원하는 일인 사용자용 마이크로블로그 소프트웨어입니다.
이번 버전의 주요 변경점은 다음과 같습니다.
@nprofile…m60y 님의 기여로 이제 S3 대신 로컬 파일시스템에 미디어 파일을 저장할 수 있게 되었습니다. DRIVE_DISK=fs 및 FS_ASSET_PATH 환경 변수를 설정하면 미디어 파일들이 로컬 파일시스템에 저장되게 됩니다. S3를 사용하시던 분들은 따로 취해야 할 행동은 없지만, 가급적이면 DRIVE_DISK=s3 환경 변수를 설정해 두실 것을 권합니다. (나중 버전에서 DRIVE_DISK 환경 변수가 필수가 될 예정입니다.)
Sentry를 지원하게 되었습니다. Sentry에서 오류 보고나 트레이스를 확인하고 싶으신 분들은 SENTRY_DSN 환경 변수를 설정해주세요.
프로필 페이지에 페이지네이션이 추가되었습니다.
Fedify를 1.3.0으로 업데이트함에 따라 여러 성능 개선 및 버그 수정이 이뤄졌습니다.
Hollo 0.3.0으로 업데이트하시려면 아래 방법을 따르시면 됩니다.
Railway 사용자: Hollo 서비스를 다시 디플로이하면 됩니다.
Docker 사용자: Hollo 이미지를 ghcr.io/dahlia/hollo:0.3.0 또는 latest로 올려 주시면 됩니다!
수동 설치자: Git에서 stable 브랜치를 받으시면 됩니다.

2024-12-01 04:39:06 UTC

Hollo 0.3.0 released! #Hollo is a single-user federated microblogging software which is #ActivityPub-enabled and powered by #Fedify.
The key changes of this release include:
Thanks to @nprofile…m60y, Hollo now support local filesystem storage for media files. You can configure DRIVE_DISK=fs and FS_ASSET_PATH to store media files in the local filesystem. For users who've used S3, no further action is required—but, it's recommended to configure DRIVE_DISK=s3 as DRIVE_DISK will be required in the future releases.
Added support for Sentry. If you want to see error reports and instrumented traces in Sentry, please configure SENTRY_DSN.
Added pagination to the profile page.
Minor performance improvements and bug fixes due to upgrading Fedify to 1.3.0.
You can upgrade to Hollo 0.3.0 using the following ways:
To Railway users: Just redeploy the Hollo service!
To Docker users: Switch your Hollo image to ghcr.io/dahlia/hollo:0.3.0 or simply latest!
To manual installers: Fetch the stable branch and switch over to it!

2024-11-22 09:38:36 UTC

The #Hollo v0.2.3 has been released, which fixes a few bugs and brings #Fedify to the latest version, v1.2.7. If you are using the Docker image, you can upgrade by using the ghcr.io/dahlia/hollo:0.2.3.

2024-10-22 07:56:15 UTC

Finally, Hollo 0.1.0 released! #Hollo is a single-user federated microblogging software which is #ActivityPub-enabled and powered by #Fedify.
Hollo has the most of features that Mastodon has except for moderation tools, and also include:
CommonMark (a.k.a. Markdown) and up to 4,096 characters per post
Misskey-style quotes (compatible with Misskey, Akkoma, Fedibird, etc)
Misskey-style emoji reactions (both Unicode emojis and custom emojis are supported; compatible with Misskey, Akkoma, kmyblue, etc)
Generally much relaxed limitations (more poll options, more attachments, and so on)
… and many more!
If you're interested in Hollo, please give it a try! There are several ways to install it: using Railway, using Docker (and Docker Compose), or manually.
If you're already using Hollo, please upgrade it to v0.1.0:
To Railway users: Just redeploy the Hollo service!
To Docker users: Switch your Hollo image to ghcr.io/dahlia/hollo:0.1.0 or simply latest!
To manual installers: Fetch the stable branch and switch over to it!

2024-10-20 17:13:50 UTC

The most common pitfall for first-time #Hollo users is deploying Hollo behind a reverse proxy and forgetting to set BEHIND_PROXY=true, which causes federation issues and wasted time trying to resolve them.
To help users avoid this common pitfall, we've introduced a warning on Hollo's setup page when Hollo is behind a reverse proxy and the BEHIND_PROXY is off.

2024-10-15 08:31:57 UTC

We now have #Hollo and #Fedify's official #Discord server! Join us now!
https://discord.gg/hGXXxUq2jK

2024-10-14 16:24:18 UTC

We now have a Matrix room for #Hollo users: #hollo-users:matrix.org. Join us now!

2024-10-11 17:17:31 UTC

#Hollo now allows you to write custom emojis! :hollo: :fedify: :fediverse:

2024-10-08 09:18:32 UTC

Hollo公式サイト兼ドキュメントに日本語が追加されました！
https://docs.hollo.social/ja/