Huh. Radicle web app has a new look. Example: https://app.radicle.xyz/nodes/radicle.dpc.pw
Pushed and deployed on https://rostra.me. A bit tighter spacing.
one thing Iād prefer is, that right now there is too much āwhite spaceā on the page. The posts are too far apart. That reduces the amount of information. Iām not suggesting making it too tight, because obviously youād have a preference, but it would be a good idea to test slightly tighter design.
On that note, can you share how I would go about changing the style.css if I wanted to try something else in overall design? Like could I use some AI tool or something else, and which tool?
The simplest way would be to use some usercss browser extension. It would be relatively easy to customize the style.css in the source code, or even add some command line argument for the code to include extra stylesheets, but it doesnāt seem very popular and will probably break often as I am making further changes.
I think I agree that some spacing here and there could be reduced anywayā¦
I am getting this error ,
2026-03-03T11:08:13.212458Z WARN RemoteStateActor{me=48c97d2e0b remote=1c25c3ef9c}: iroh::socket::remote_map::remote_state: Address Lookup failed: Service 'dns' error: no calls succeeded: [Failed to resolve TXT recordFailed to resolve TXT recordFailed to resolve TXT record]
2026-03-03T11:08:13.457974Z WARN RemoteStateActor{me=48c97d2e0b remote=1c25c3ef9c}: iroh::socket::remote_map::remote_state: Address Lookup failed: Service 'dns' error: no calls succeeded: [Failed to resolve TXT recordFailed to resolve TXT recordFailed to resolve TXT record]
2026-03-03T11:08:13.710369Z WARN RemoteStateActor{me=48c97d2e0b remote=1c25c3ef9c}: iroh::socket::remote_map::remote_state: Address Lookup failed: Service 'dns' error: no calls succeeded: [Failed to resolve TXT recordFailed to resolve TXT recordFailed to resolve TXT record]
2026-03-03T11:08:13.968096Z WARN RemoteStateActor{me=48c97d2e0b remote=1c25c3ef9c}: iroh::socket::remote_map::remote_state: Address Lookup failed: Service 'dns' error: no calls succeeded: [Failed to resolve TXT recordFailed to resolve TXT recordFailed to resolve TXT record]
This when I run latest rostra on localhost.
2026-03-03T11:09:20.715876Z WARN RemoteStateActor{me=48c97d2e0b remote=cbd8d6c728}: iroh::socket::remote_map::remote_state: Address Lookup failed: Service 'dns' error: no calls succeeded: [Failed to resolve TXT recordFailed to resolve TXT recordFailed to resolve TXT record]
2026-03-03T11:09:21.017877Z WARN pkarr-id-publisher{self_id=rsut5j319xfrsr8ud3rgua8nmxmh}:connect{me=48c97d2e0b alpn="rostra-p2p-v0" remote=ed95c5f044}: iroh_quinn_proto::connection: remote server configuration might cause nat traversal issues max_local_addresses=12 remote_cid_limit=5
http://[::1]:3377/profile/rsut5j319xfrsr8ud3rgua8nmxm6kegcjjggijc6te5ein4tyjw8my
https://rostra.me/profile/rsut5j319xfrsr8ud3rgua8nmxm6kegcjjggijc6te5ein4tyjw8my
my localhost profile vs rostra.me profile, for reference.
google.com
reddit.com
http://www.google.com
https://google.com
www.google.com
Testing what urlās are clickable.
looks like only djot style links are clickable.
W.r.t. vibe coding, LLM-assited SWE, I think weāre going to need to wait a long time.
In my experience it takes at least a year, and sometimes even 3 years from the time a given software project starts to be worked on in real-life business settings, until it really fully develops, settles and ācracks begin to showā.
Initially everything is great. Biz is painting beautiful visions, devs are adding features, bugs are fixed and everything progresses relatively fast.
But sooner or later a successful projects starts gaining users, features, use-cases, workload and only then you get a real feedback on how actually well (or not) was it designed and implemented. Stuff like: architecture turned out way slower than expected, data loses due show up, certain things canāt be implemented at all because of deficiencies of the data model. The more or less implicit āthis happens once in a million, so itās not an issueā begin to appear. Some original authors left, and understanding the system is hard. The test suite got large, and now itās way too slow. With actual workloads the cloud bill become (very) substantial. The āsimpler approachā accumulated bunch of hacks for things it didnāt handle, and now is not simple at all.
My point being - only after longer period you get to see the lasting long term consequences of your technical decisions.
With LLMs I expect it to be somewhat similar. What are the efficient ways to handle LLM, how much to let it do things vs hold its hand, what patterns of harnesses and methods to use. You canāt judge it too early.
@dpc feature:
When I do āpreviewā, it brings up that box that has two buttons, ācancelā and āpostā.
āCancelā should be renamed to āedit moreā , because it actually allows us to edit more. Cancel implies we are completely cancelling the post, and it seems as if we would lose the text if we ācancelā.
The amount of basic bugs and limitations in IronClaw is making this (IronClaw-based) bot not really actually viable ATM. The agent skill would likely work much better in some other (more complete) claw implementation, and possibly in some near future version of IronClaw.
But it is still great to play with this idea.
I have added a agent skill for LLMs to post on Rostra and that works and I had a claw post something successfully, but this method required LLM to share the secret with the server, which would be passable for now, but even more of a problem is that thereās currently no way for the LLM to safely store the secret at all.
Then I started implementing a WASM tool - extension for IronClaw which would allow the agent to sign things on the client side, isolated from the LLM itself, and it would be relatively easy to move the whole core logic into WASM, thus having a no-security compromises integration with Rostra for agents, but Iām hitting a blocker of not being able to properly use secrets at all in the WASM sandbox.
Update: What is happeningā¦