Hollo

We'll be releasing #Hollo 0.4.0 before the year is out. Stay tuned!

Just released #Hollo 0.3.5, which contains small minor bug fixes.

@laravista Hi, there!

Starting with #Hollo 0.4.0, you can allow your profile to be discovered in the public directory. Under the hood, this option corresponds to Mastodon's toot:discoverable property.

My webcam posting bot is working with @hollo #nodeRed and some LLM to help with description and alt text.
Now to figure out what it should actually do

A Call for Better Activity Signatures in the Fediverse

Why Major ActivityPub Implementations Should Adopt Object Integrity Proofs

Let's say you have accounts named alice@bar and bob@baz that don't follow each other, but they both follow john@foo. When alice@bar replies to john@foo's post, how can bob@baz see this reply?

This problem applies not only to replies, but also to things like likes and emoji reactions. One of the ways that ActivityPub implementations solve this problem is through inbox forwarding. The idea is to forward the reply received by john@foo to bob@baz as well.

Fedify makes inbox forwarding easy and convenient with its forwardActivity() method. But the question is, can bob@baz trust the activity forwarded by john@foo?

Because HTTP Signatures sign the HTTP request that contains the activity, not the activity itself, john@foo can't sign an activity created by alice@bar when it's forwarded by him, because forwarding requires creating a new HTTP request. (The HTTP request includes things like the Host header, so a new signature is required for each new recipient.)

So, alice@bar needs to sign her activity in a way that allows john@foo to forward it. In the fediverse, there are two ways to do this: Linked Data Signatures and Object Integrity Proofs. Fedify automatically attaches all three types of signatures (HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs) to every activity it sends, so activities are free to be forwarded between ActivityPub software created with Fedify.

However, major ActivityPub implementations such as Mastodon and Misskey still sign activities with HTTP Signatures only, or only some activities with Linked Data Signatures. (Note that Linked Data Signatures is an outdated standard, and Object Integrity Proofs are recommended.)

So, why are we talking about this at length? We strongly urge major ActivityPub implementations to adopt Object Integrity Proofs, or at minimum Linked Data Signatures, for activity signing!

Hollo 0.4.0からTIMELINE_INBOXESという実験的なオプションが追加されます。このオプションをtrueにすると、ホームタイムラインとリストタイムラインが要請されるたびに投稿がリアルタイムでフィルタリングされる代わりに、データベースに各タイムラインごとにインボックスが作成され、そこに投稿が入ります。その為、このオプションをオンにした直後は、タイムラインが空っぽに見える事が有ります。

このオプションをオンにすると、多くのアカウントをフォローしているアカウントでパフォーマンスが向上しますが、まだバグが有る可能性が有ります。しかし、機能が安定化したら、このオプションがデフォルトの動作に成る予定です。

Hollo 0.4.0부터는 TIMELINE_INBOXES라는 실험적인 옵션이 추가됩니다. 이 옵션을 true로 하면 여러분의 홈 타임라인과 리스트 타임라인이 요청할 때마다 게시물들이 실시간으로 필터링되는 대신, 데이터베이스에 각 타임라인별 인박스가 생기고 거기에 게시물들이 들어가게 됩니다. 따라서, 이 옵션을 켠 직후에는 타임라인이 비어 보일 수 있습니다.

이 옵션을 켜면 많은 사람을 팔로하고 있는 계정에서 성능이 향상되지만, 아직 버그가 있을 수 있습니다. 하지만 기능이 안정화되고 나서는 이 옵션이 디폴트 동작이 될 예정입니다.

Starting with Hollo 0.4.0, we're adding an experimental option called TIMELINE_INBOXES.

If this option is set to true, instead of your home timeline and list timelines filtering posts in real-time whenever they are requested, the database will create an inbox for each timeline and put posts into it. As a result, your timelines may appear empty immediately after turning this option on.

Turning this option on will improve performance for accounts that follow a lot of accounts, but it may still be buggy. However, once the feature is stabilized, this will be the default behavior.

@thisismissem We haven't tested it out, as it requires much more changes to the Hollo code.

Okay, testing #Hollo with #Node.js is cruising along. It's consuming up to 3 GB of memory at peak times, but that's a huge improvement over Hollo with #Bun, which was consuming over 8 GB of memory at peak times.

So, yes, starting with Hollo 0.4.0, we'll use Node.js instead of Bun!

@Adrian There are APIs to create an application and to authenticate.

#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.

The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!

Are you interested in trying out the Node.js version of Hollo early? Try to pull ghcr.io/dahlia/hollo:0.4.0-dev.290!

Yay! 🥳🎉🎊🙌🏼

https://tapbots.social/@ivory/113659885091954331

@hollo This will change in the next update. We will soon support alphanumeric post ID’s.

実はウェブフロントエンドに門外漢なので全部サーバーサイドレンダリングで実装しましたが、ブラウザ側のJavaScriptが無くても動くという副次的な効果が有りますね！

https://mstdn.maud.io/@Coro/113647432273436454

Hollo、Javascript 無しでもほとんど閲覧できるの好き。microblogpub の良い所を受け継いでる感じがする

https://hollo.social/@hollo

@hollo @ivory same issue with gotosocial and iceshrimp.net I believe

For those who want to use #Hollo on @ivory: #Ivory evolved from the Tweetbot codebase, which was a third-party Twitter client, so it assumes that object IDs are integers. Hollo uses UUIDs for object IDs, so it can't be used with Ivory at this time. We hope that Ivory will support non-integer object IDs in the future!

意外(의외)로 Hollo에서 支援(지원)하는 機能(기능)들!

• Markdown
• 引用(인용)
• 繪文字(회문자)(에모지) 리액션

https://buttersc.one/notes/a1mrh9mfbv

Hollo 是一款无头微博软件，它实现了 Mastodon API。 这意味着您可以使用任何与 Mastodon 兼容的客户端与其进行交互。 然而，实际上，由于 Mastodon API 的实现方式不同， 某些客户端可能无法按预期工作。 以下是一些经过 Hollo 测试的客户端。

https://docs.hollo.social/zh-cn/clients/

FedifyやHolloの開発を支援したい方は、GitHubでスポンサーになってください！

https://github.com/sponsors/dahlia
QT: https://fosstodon.org/@hongminhee/113571131696464837 [参照]

Hollo update to v0.3.0 🎉

#전국_연합우주_서버장들이_말하는_자기_서버_특징 순정 홀로 서버

Hollo 설치하는 김에 Obejct Storage나 써 보자, 하고 OCI S3 호환 문서 보고 설정하고 있었는데 어 그 사이에 0.3.0이 릴리즈 되면서 로컬 FS가 생기고 문서가 바뀌었다. ㅋㅋㅋ

덕분에 편하고 빠르게 바로 설치. 현재 테스트 중입니다.

Hollo in #Moshidon

#Hollo

Hollo 0.3.0이 릴리스되었습니다! Hollo는 ActivityPub을 지원하는 일인 사용자용 마이크로블로그 소프트웨어입니다.

이번 버전의 주요 변경점은 다음과 같습니다.

• @joschi 님의 기여로 이제 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 브랜치를 받으시면 됩니다.

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 @joschi, 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!

If you'd like to support the development of @fedify or @hollo, you can sponsor me on GitHub!

https://github.com/sponsors/dahlia

#fedidev

I don’t have my test instance completely set up with S3 for media but pretty sure #Fedicat is working with #Hollo now.