Unless there are bits in the lj code that explicetly refer to everything as http - as opposed to relative urls, it would simply be a matter of webserver configurationing (and, obtaining an ssl key, which isn't the cheapest thing in the world, alas).

Most client code would, i'd imagine, be able to easily add in ssl support. I think i'm going to make sure that the library i'm doing will do ssl - (it might be worth it for me to grab the lj code and set it up under an ssl server, just to play with it)...

--Dg

Most webservers don't run SSL without leaving at least some plain http access. The way I forsee LJ doing this with the lowest impact would be to allow https access, say, to /interface/flat
I don't think anyone would want to require it and it doesn't make sense for all occasions.

Clients would then have the option of linking in, say, the library from www.openssl.org (or the perl module which uses it, or whatever) if their users wanted to use the SSL interface option.

The only thing I can think of is the possible cost of aquiring an officially certified certification. The instructions on how to create your own cert are readily available but having a non-official cert will give users using browsers funky error messages unless/until they accept the cert permanently.