It’s a great thread indeed. No thread-handling issues here btw 😎

himmel.app

Thanks for the deer, it took some tweaking to fix the transition 😎

Version 1.0.2 has been released. This release adds an option to toggle autoplay for videos. I'm also adding the option to change the app language. I'm starting with the translations that I can ask friends and family to check for correctness. Currently Swedish, German and Dutch have been added.

Do you prefer reading your timeline from top to bottom?
The "add new posts at the bottom of the list"-feature is for you! ❤️

Shortcut alert: tap the feed name to scroll to the newest post in the feed. 👍🏻

Himmel for iOS and Android An offline-capable feed reader for Bluesky with simplicity in mind.

For offline feed reading on trains with bad WiFi I built @himmel.app. Offline likes get applied when you are online again. One button to update all your feeds! 😎

I guess I could slap a MAC on the request? Less trivial to use the endpoint but not secure ofc. Is it even possible to limit access to only the client in the native case?

Anyone would be able to generate a client assertion though, since the endpoint must be open. Would this be a security issue?

It would be great to have the lexicons. I would love a lightweight backend to elevate @himmel.app to the coveted confidential status! 😊

Nice! Can it be used by native clients too?

post your pinned feeds

OAuth is great, but for mobile apps there is still the issue of users having to reauthenticate every two weeks. Can be overcome with a backend but significantly increases complexity for developers.

There are efforts to bring community notes to Bluesky. Currently @bluenotes.social offers a beta client where everyone can add community notes. The great thing is that the notes themselves can be displayed in any Bluesky client, with very little effort from developers.
bsky.app/profile/jona...

Still putting it off due to having to sign in again every two weeks…

I share your weariness. A good thing is there is a fork at getflocked.dev in case Google decides to drop Flutter in the future. I’ve only worked with iOS and Android so far, not web.

I can really recommend @flutter.dev for cross-platform apps. Code reuse close to 100% for me.

Himmel is designed with a focus on reading, so it's not a fully featured client. You can like posts in the app when offline, and the likes will be applied when you're online again.

For replying and reposting, tapping on a post will take you to that post in the official Bluesky client.

Want to read your feeds on your WiFi-less flight? One button before boarding is all you need! 😎

Looks interesting. Support for non bsky PDSes would be appreciated.

Screenshot of the Himmel app showing a post claiming the Nobel committee removed Donald Trump's name from the nominee list and a community note showing this is not true.

Experimenting with community notes in the app, courtesy of @bluenotes.social. Anyone can contribute!

Version 1.0.1 has been released.

This release only contains minor bug fixes and improvements.

Do you prefer reading your timeline from top to bottom?
The "add new posts at the bottom of the list"-feature is for you! ❤️

Great, looks pretty straightforward!

Very cool! How can a third-party Bluesky client show community notes? Can they be fetched from somewhere?

Commodore data cassette drive.

Good times!

Tested it on my PDS (Bluesky PDS 0.4.169) and it works. Very easy way to make a confidential native client but only if you set the app type to "web". The Bluesky PDS implementation does not allow confidential native clients. Source code comments indicate that could change in the future though.

Using the "dynamic client id" approach may avoid some of the DCR drawbacks since only the public key originates from the client. OTOH different issues would likely arise, such as the fact that the client id will always return an "in use" public key even though it may not be in use anymore.

The DCR proposal could accomplish the same thing and looks a lot cleaner. I hope it's being considered for atproto.

blog.smokesignal.events/posts/3lvtim...

Yes, it should be doable. Just wondering if it would be seen as abusing the system. In the docs, confidential clients seem to always reside on a web server.

Hmm, I guess I can let every device register their public key on the app server and then serve dynamic client_id documents to let the device authenticate as a confidential client. Sounds a bit dodgy though.