Hello there. I just subscribed and I thought I would drop an email to introduce myself.
I'm playing with laconica with a local install (http://micro.fit-factor.net/ - already added to ListOfServers - official language is Italian - open to everyone) and I already went on to flood the irc channel with questions :) I'm having problems with your Trac and a.t.m. I can't add / edit content (already in touch with foucault about this), so I collected some stuff here and there and I'll paste them in this message. I'll be happy to discuss any one of these, maybe in separate threads to keep things clean. Sorry if it seems a lot of things :) Please forgive me if I say/ask something stupid, I'm just a beginner here. Before leaving you to the tedious list, let me thank everyone for the great work in providing us laconi.ca! SOURCE CODE and friends - you include php-openid 2.1.1, while 2.1.2 is out. I put it on my systems and seems to work well so far - incoming email settings in user's profiles should be hidden when the service isn't available (or via a config.php option) - same holds true for the SMS tab INSTALL / DOCUMENTATION - everything OpenID related will implode at markdown.php with an, otherwise good, memory_limit setting in php. Trying to login via OpenID or even just accessing the OpenID tab in user settings. On my linux x86_64, apache-2.2, php-5.2 system, it goes nuts with 8650KiB of memory_limit, works with 8750KiB. I'm running with a 10MiB limit now. While this is not a bug, you could outline the thing in some INSTALL related documentation. - http://laconi.ca/trac/wiki/Installation says that you need GMP for OpenID. I'm running with a --without-gmp php 5.2 and a friend of mine created an account with a Blogger.com OpenID, logged in and posted a dent. I added a Flickr OpenID to my otherwise standard account. Maybe GMP is no more needed? - when looking for info about incoming / outcoming email, it is easy to skip over the relevant part of the README since it's under the 'SMS' section. Making two distinct sections, EMAIL first and SMS after that would be better imho. - /dev/urandom: * lib/util.php:1665 looks for dev/urandom. This made ugly warnings appear if not available. I reported this on IRC and it got a @ added solving the warnings. * Auth/OpenID/CryptUtil.php absolutely needs access to /dev/urandom or it won't work - and thus OpenID won't work either * on security-conscious php sites many administrators put open_basedir restrictions in place and they don't usually permit /dev/ urandom * you should suggest in the install docs to permit access to /dev/ urandom (not to the whole /dev !!!) for better security and list it as a prereqisite to OpenID functionality - the included README and the wiki Installation documents have mixed contents, sometimes overlapping and sometimes not, are out of sync (see the GMP issue above). I propose to write a single document, with two macrosections (one for users, one for administrators), and source the wiki page to build the README file. Or track it with darcs. Or whatever. RUNTIME BEHAVIOUR - a user can change his nickname, but this will break all @replies in the past. Don't know if this is ok or not, and don't know what solution to eventually recommend. - a user can delete his dents, but relevant records in the notice_tag table doesn't get deleted. So you can end up with no-more-existent tags showing up in /tags - in settings -> email there's a textbox to add one's "Email address". But after adding it, the same textbox/label descriptions talks about "Jabber / GoogleTalk Account" when waiting for confirmation and after confirmation. This different wording could be confusing for the end user - at least it was for me :) WOULD LIKE TO SEE... - I quickly added Google Analytics support putting the js code (with my id hardcoded) in the common_show_footer() function and I output it with common_raw() between the last </div> and the </body>. If you find that it could be useful to other, you could put the same code and define a config key for the id, if it's not empty then emit the js code otherwise don't - to get incoming mails (to post dents via email) one needs to run the maildaemon.php as a filter on a system that A) is the final mailserver for the domain and B) has laconica credentials stored on it and C) has access to the database holding laconica data. You won't get anything like this on "standard" hosting places and even building your own system this is not such a good setup. Think about different system handling web and mail in a production environment. It would be great to have (maybe as a second option) a daemon (would run with your other current daemons) that keeps an IMAP connection open to a mailbox of choice and gets mail via that. Just like the XMPP daemon does for incoming dents - I can't really understand why you need to generate random mail addresses for incoming data. I didn't try post-by-email (see previous point for the reason) but I hope you have some kind of authentication - just posting everything that gets to the (more or less random) mail address is an open door for lots of bad things and makes the server side setup more difficult (you need to get mail via a catch-all for the whole domain). Why not a single incoming address (would simplify / make possible the proposed IMAP thing) with three lines of text per message: user, password, status message ? - a different solution: a script on the mail server that connects to the api via http. It would use user credentials from the message contents and post stuff. - every user should be able to set the theme he'll see when logged in. should be easy to do and shouldn't affect others. - templating! please! working with the current, fixed, XHTML output could be... frustrating, at best. If you want to attract users you need fancy themes. If you want fancy themes you have to make the XHTML more-or-less-easily modifiable. You don't need a bloated templating engine, just split the content-generating parts in a few functions and write native php templates that call those functions. Like wordpress, you know :) - a good doc about federation: how and why. - some sort of high-level statistics - maybe track in the database and/ or provide functions/webpages to easily get total number of hits, posts, users, subscriptions, statistics about outgoing traffic, xmpp traffic, etc. WOULD LIKE TO LET YOU KNOW... - that I completed most of the Italian translation, many of my suggestions are already approved and more are there in the queue. Probably only a dozen or so strings are not translated at all... things I don't know where to find/check in laconica - that gouki was kind enough to grant me validator status for it_IT - that laconica seems to work without problems when using the Suhosin hardening patch on PHP - that any Italian-speaking guy is welcome to use http://micro.fit-factor.net/ - international users are welcome too, but I think the microblog will have near 100% Italian messages WOULD LIKE TO KNOW... - if remote profiles / avatars are supposed to get updates after the initial subscription and how (push them when a user changes his settings?) - how do you think to handle internationalization for the /doc/ files -- Luca Lesinigo _______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
