dw_dev | Question thread #147

Entry tags:

questions

Question thread #147

It's time for another question thread!

The rules:

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

Flat | Top-Level Comments Only

One of my very few regrets about Dreamwidth is that there is no app for it, so it's just about impossible to read on my phone. I seem to remember reading at some point that the reason there is no apo is because the Dreamwidth API would need to be completely rewritten. Which makes perfect sense, I'm sure that's a huge amount of work.

In my day job I am a software Technical Writer. And my company is ALL IN on using AI and LLMs to accelerate everything and has not put any limits (yet) on spending/tokens. While I'm not a developer, I've been quite impressed with what I've been able to accomplish using Cursor to read the code base and answer my questions. I recently had Cursor read the code base for error messages and generate troubleshooting documentation, and was very impressed with what it produced. And most of my feedback from my engineers when they reviewed my PR was "I would delete that, we don't want to tell customers that." (That is, it's not wrong, we just don't recommend that.)

So my question is, have you considered using artificial intelligence to revise the API and write an app for Dreamwidth? If it's a question of money, I'm sure I'm not the only one who would be willing to buy some AI tokens if it means we might get a Dreamwidth app.

There are many aspects to your question, and I'm not able to address most of them, but I can make educated guesses for some of them and list the ones I'm not comfortable answering even tentatively:
1- I think the server-side API rewrite has stalled partway through, due to lack of senior developer, reviewer, and tester time. (

momijizukamori, please correct me if I'm wrong about this.) Since, as far as I know, generative AI for code-writing uses is still at best at the level of a junior programmer whose code need to be carefully inspected and tested before being accepted, and the lack of reviewer (or senior developer wearing a reviewer hat) and tester is still a show-stopper for that approach. However, this may be a moot point, because...
2- Who has the copyright on AI output and therefore the right to place that code under GPL2+, as required to combine it with the Dreamwidth codebase is still, I believe, an unsettled legal issue in the US, to say nothing of the rest of the world. I think

denise and

mark will probably want to tread very cautiously here.
3- There are also ethical issues pushing against the use of generative AI for anything, which I will not address because I'm not qualified to.
4- The above, however, is distinct from developing API clients (the user-facing applications) using generative AI, using the API as it currently stands. I won't discuss this either, because I don't know whether or to what extent one could vibe-code a whole client or individual client features using the OpenAPI self-documentation feature of the Dreamwidth API as part of the prompt.

All things that we're discussing at my job as well. Oh well, I thought it was worth throwing out as a question, if only to get the conversation started on this question thread.

at the level of a junior programmer

I keep forgetting about this, as we don't have entry level programmers at my company. So all the AI coding at my job IS being supervised by senior developers.

Who has the copyright on AI output

Only humans can own copyright. I believe that the human who submits the code is presumed to be the owner, and thus can assign the open source license (My company is open source, and that's my understanding of how our legal folks are interpreting things, but YMMV).

ethical issues

I personally know people who are involved in some of the lawsuits about training LLMs on copyrighted works. And I have my own concerns about power and water usage with AI. But I pretty much have to use it if I want to keep my job, so I'm sort of gritting my teeth and getting stuff done.

Thanks for answering!

The problem with a mobile app is not just the API -- that is, as you note, technically fixable. The big issue is that both Apple and Google have significantly different content restrictions for what can appear on UGC sites that have apps in their storefronts, and those restrictions are WAY more restrictive than we want to be. So it would basically be a tremendous amount of technical work (both on the API and on the mobile app development front) and also be completely wasted because we wouldn't be able to keep the apps available except through side-loading because we wouldn't listen to their censorship requirements.

That (how to deploy the clients) would have been my 5th point had I not lost track I meant to have one. Dmamn you, attention span.

Boo on Apple and Google!

Thanks for replying!

Flat | Top-Level Comments Only

Question thread #147

This might be a bit long

Re: This might be a bit long

Re: This might be a bit long

Re: This might be a bit long

Re: This might be a bit long

Re: This might be a bit long