feat: add profile fetching from pubky

[ben-kaufman]

Summary

Integrates Pubky decentralized identity into Bitkit, allowing users to connect their Pubky profile via Pubky Ring authentication. Once connected, the user's profile name and avatar are displayed on the home screen header, and a full profile page shows their bio, links, and a shareable QR code.

What's included

• Authentication flow via Pubky Ring deep links (pubkyauth://) with relay-based session exchange, session persistence in Keychain, and automatic restoration on app launch
• Profile page displaying name, bio, links, and a QR code with the profile picture overlaid
• Home screen integration showing the authenticated user's name and avatar in the header
• PubkyService — service layer wrapping paykit (profile/session management) and bitkit-core (auth relay, file fetching)
• PubkyRepo — manages auth state, session lifecycle, and profile data with all Keychain/disk operations offloaded to background threads
• PubkyImage component for loading pubky:// URIs with two-tier (memory + disk) caching
• Suggestion card auto-dismiss when user is already authenticated

[claude]

Code review

Found 2 CLAUDE.md compliance issues.

[jvsena42]

Starting review

[jvsena42]

could use mapNotNull

[jvsena42]

Could add some unit tests at Repo level too

[jvsena42]

could use DataStore instead

[jvsena42]

Use the existing context extension method

[jvsena42]

could replace with a ViewModel injection

[jvsena42]

could be converted to Webp and imported in multiple densities using https://www.appicon.co/#image-sets

[jvsena42]

Android studio can convert it

[ovitrif]

Reviewed up to and including PubkyImage.kt, will resume later.

Test Recording:
https://github.com/user-attachments/assets/fc3f6997-981e-422f-92e4-60769232bd3d

Manually tested and found 2 critical, pls see video above:

1. Crash when trying to go to Profile via Drawer.
2. Dialog should use AppAlertDialog which comes with theming for our design lang.

Plus a couple nits, strongest views on:

• using viewModel and no business logic in UI layer
• using DataStore instead of SharedPreferences.

---

Aside from these small things, it works great 🎉

[ovitrif]

nit: could return Result<Boolean> to signal if successful

Edit: fixed to show what I meant using the inline code block.

[ovitrif]

nit: it's better to refactor this to use .recoverCatching{} and .mapCatching {} chaining.

[ovitrif]

Completed review ✔️

Lots of small nits, but normally Claude Code or Cursor Agent should be able to just go over all comments and address them if prompted to do so. Might need GitHub MCP or gh (GitHub CLI) installed locally.

[ovitrif]

nit: pls check if some slashtags__ prefixed strings are still used or can be removed.

[claude]

Three issues in this catch block per CLAUDE.md:

1. Use Result API instead of try-catch: "ALWAYS use the Result API instead of try-catch"
2. Exception manually appended to message: "NEVER manually append the Throwable's message or any other props to the string passed as the 1st param of Logger.* calls" — pass it as the e argument instead
3. Missing context = TAG: "ALWAYS pass the TAG as context to Logger calls" — no TAG constant exists in this object

Suggested fix:

Suggested change

	override suspend fun readFrom(input: InputStream): PubkyStoreData {
	return try {
	json.decodeFromString(input.readBytes().decodeToString())
	} catch (e: SerializationException) {
	Logger.error("Failed to deserialize PubkyStoreData: $e")
	defaultValue
	}
	}
	override suspend fun readFrom(input: InputStream): PubkyStoreData {
	return runCatching {
	json.decodeFromString(input.readBytes().decodeToString())
	}.getOrElse {
	Logger.error("Failed to deserialize PubkyStoreData", it, context = TAG)
	defaultValue
	}
	}

Also add a companion TAG constant to this object:

private val TAG = PubkyStoreSerializer::class.simpleName

[claude]

Claude finished @ovitrif's task in 1m 0s —— View job

---

• Read PubkyStoreSerializer.kt for context
• Analyze Kotlin semantics for this::class.simpleName in object
• Post answer

---

Answer: this::class.simpleName in a Kotlin object

Technically it works, but private const val TAG = "..." is preferable. Here's why:

What works

In a Kotlin object, this refers to the singleton instance and is accessible in property initializers, so this compiles:

object PubkyStoreSerializer : Serializer<PubkyStoreData> {
    private val TAG = this::class.simpleName  // compiles ✓
}

The catch: nullable String?

KClass.simpleName returns String? (nullable) — it's null for anonymous objects and local classes. So TAG would be typed as String?, which means passing it to Logger.error(..., context = TAG) passes a nullable where a String is expected — this would likely cause a compile error or require a !!/?: "" workaround.

Why const val is better here

private const val TAG = "PubkyStoreSerializer"  // String, non-null, compile-time constant ✓

• Non-nullable — no workaround needed
• Compile-time constant — inlined at call sites (no runtime overhead)
• Established pattern — matches every other serializer/class in the codebase

Summary

this::class.simpleName is fine for logging in regular classes (where you can store it as String? and pass ?: javaClass.simpleName), but for object declarations the const val approach is strictly better. The file already has the correct implementation.

[claude]

Race condition with loadProfile()

signOut() does not acquire loadProfileMutex, creating a race condition with loadProfile():

1. loadProfile() acquires the mutex and suspends inside pubkyService.getProfile(pk) (network I/O)
2. signOut() runs concurrently, clears _publicKey, _profile, and sets auth state to Idle
3. loadProfile() resumes, writes the fetched profile back to _profile (line 180), and calls cacheMetadata() — restoring stale data after sign-out

The result: after sign-out, _authState is Idle but _profile and pubkyStore contain the previous user's data, causing the UI to display a stale profile for an unauthenticated user. On next cold start, the cached name/image will be shown again.

bitkit-android/app/src/main/java/to/bitkit/repositories/PubkyRepo.kt

Lines 183 to 197 in 1985f9e

	suspend fun signOut(): Result<Unit> = runCatching {
	withContext(ioDispatcher) {
	runCatching { pubkyService.signOut() }
	.recoverCatching {
	Logger.warn("Server sign out failed, forcing local sign out", it, context = TAG)
	pubkyService.forceSignOut()
	}
	runCatching { keychain.delete(Keychain.Key.PAYKIT_SESSION.name) }
	runCatching { imageCache.clear() }
	}
	pubkyStore.reset()
	_publicKey.update { null }
	_profile.update { null }
	_authState.update { PubkyAuthState.Idle }
	}

Fix: either have signOut() acquire loadProfileMutex before clearing state, or re-check _publicKey.value inside loadProfile() after the network call completes (while still holding the mutex) and skip writing if it is null.

[ovitrif]

Submitted couple more pending comments and resolved the ones where code changes applied. The goal is to reach a state where agent can be asked to scan through non-resolved review comments and address those in a new pass.

[ovitrif]

nit: may use more general name like pubky.json or an extension thereof which doesn't force this to profile only. ultimately these are jsons they can support even lists => name can be more generalistic

[ovitrif]

yes, normally onSuccess and onFailure are meant for side effects, for chaining it's, recommended to use mapCatching

[claude]

• Analyze this::class.simpleName for TAG in different Kotlin contexts
• Check codebase patterns

---

Answer: private val TAG = this::class.simpleName — works in some contexts, breaks silently in others

Short answer: it's not safe to standardize on, specifically because of how companion objects work.

---

Where it works ✅

Context	this::class.simpleName returns
Regular class body	"MyClassName" ✓
object declaration (e.g. PubkyStoreSerializer)	"PubkyStoreSerializer" ✓

Where it silently breaks ❌

companion object — which is the dominant TAG pattern in this codebase:

class MyViewModel : ViewModel() {
    companion object {
        private val TAG = this::class.simpleName  // returns "Companion", not "MyViewModel" ❌
    }
}

Inside a companion object, this refers to the companion object singleton itself, so .simpleName returns "Companion" — your logs would show Companion as the tag for every class.

Nullable return type ⚠️

KClass.simpleName returns String? (nullable). It's null for anonymous classes. You'd need ?: "Fallback" everywhere, or use !! which is banned by CLAUDE.md.

Not a compile-time constant ⚠️

val (not const val) means it's evaluated at runtime and can't be used in annotations.

---

Codebase verdict

Looking at the codebase, every TAG is a private const val TAG = "ClassName" string literal — in companion objects for ViewModels and as top-level private const val for files/objects. Given that the companion object pattern dominates, this::class.simpleName would produce wrong values for the majority of usages.

If you wanted to avoid the string literal, the only safe cross-context alternative would be:

// In companion object — reference the outer class explicitly:
companion object {
    private val TAG = MyViewModel::class.simpleName ?: "MyViewModel"
}

But this still has the nullable issue and isn't a const. The const val string literal is the cleanest option here and matches all existing patterns in the codebase.

View job run