commit 4e601cf1c725538d1d2c067e841c07fa72cf07fb Author: PSYC Date: Mon Jan 26 20:21:29 2009 +0100 let the past begone in cvs land. welcome to igit igit! diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..c6b0771 --- /dev/null +++ b/.gitignore @@ -0,0 +1,15 @@ +CVS +~$* +.DS_Store +.metadata +.actionScriptProperties +*~ +*.swf +*.swp +*.diff +*.orig +*.rej +*.log +*.pem +*old +*bak diff --git a/AGENDA.txt b/AGENDA.txt new file mode 100644 index 0000000..25addfc --- /dev/null +++ b/AGENDA.txt @@ -0,0 +1,119 @@ +VERSION 1.0 +=========== + +psyced: + [x] make those methods carry the names they should carry + [x] interface cmd() to psyc user object + [x] have pr() produce something useful for psyc clients + [x] send incoming psyc client messages as its user object + [x] allow for remote buddies (even if only java can talk to them) + [x] output real buddies + [x] make rooms usable from psyc + [x] write up some docs / installation instructions + [-] fix up the veChat applet + +web: + [x] multilang + [x] end-user start page + [x] hacker page + [x] software download + [x] konr@d disclaimer + [-] finish up the psyc draft to match psyced-1.0 + [x] www.psyced.org + [x] provide driver binaries on download + [-] provide ready-to-use packages (rpm, deb, ebuild..) + +general: + [-] set up mailing lists + [x] beta testing + [x] get it all working + [ ] heldensaga wants to celebrate a release party! + +promotion: + [x] konr@d interview + [x] freshmeat + [ ] iX article + [ ] radio bremen interview + [ ] publish in comp.sources.unix and de.comm.chatsystems + [ ] /. + [ ] less old-fashioned ideas + + + +VERSION 1.1 +=========== + +psyced: + [x] fix irc client access to server + [-] fix /p & co, or think of something better + [x] server intercommunication (buddies, messages, query) + [+] real psyc rooms + [-] filter incoming psyc vars & recognize abbrevs + [ ] support compact methods and vars + [-] proper support for var modifiers + [x] support _tag for request/reply tagging + [x] parse notice syntax: "There are [_users_amount] users online." + +perl: + [x] tcp support + [x] smart multiplexing + [x] parse notice syntax: "There are [_users_amount] users online." + [x] simple client + +general: + [ ] update & publish internet drafts + +web: + [x] about.psyc.eu + [x] comparison psyc vs. icq, jabber, msn, irc + + +VERSION 1.2 +=========== + +psyced: + [x] enter remote rooms (simple style) + [ ] make rooms fully capable of psyc + [x] make remote people addressable by nickname (local nickspace) + [ ] make user objects fully capable of psyc conferencing (hard!) + +web: + [?] the psyc vision (document) ? + +perl: + [+] non-blocking writes using buffers + [-] tkperl client + +all: + [+] start development of negotiations (see FORK) + + +VERSION 2.0 +=========== + +web: + [ ] release PSYC 1.0 specification + +all: + [ ] introduce compressed keywords + + +VERSION 3.0 +=========== + + [ ] introduce object descriptions + + +POSSIBLE FUTURES +================ + [-] c/c++ implementation (for windows, mac and unix) + [-] psyc: plugins for browsers (so you can click on a psyc url) + [x] icq gateway (so you can talk to icq-buddies from psyc) + [x] ircserver gateway (so you can talk to ircers) + [ ] pager/gsm-sms gateways + [-] psyc-enhanced videoconferencing/internet-telephony + [ ] psyc-enhanced broadcasting (text/video/audio) + [ ] psyc-enhanced distributed webcasting/website management + [-] psyc-enhanced file sharing + + diff --git a/BANNER b/BANNER new file mode 100644 index 0000000..f1c6a65 --- /dev/null +++ b/BANNER @@ -0,0 +1,9 @@ + ___________________________ + the future is in your hands + ___ __ _ · _ __ + | ·\ (__ \ / / + |__/ · \ V | · + | (__/ | \__ + + http://www.psyc.eu + diff --git a/CHANGESTODO b/CHANGESTODO new file mode 100644 index 0000000..18935e9 --- /dev/null +++ b/CHANGESTODO @@ -0,0 +1,3708 @@ +$Id: CHANGESTODO,v 1.1578 2008/04/16 16:29:04 lynx Exp $ vim:nosmarttab +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +This file contains TODO and CHANGES (at EOF) rolled into one. +Essentially: whenever you fix something, move that line to the end of file. +- marks bugs & fixes, + marks new features, ? marks issues, * marks big stuff +________________________________________________________________________ +== currently being inspected =========================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- newsfeeds hibernate when their place objects are not used! + by issuing /pl they suddenly revive. we need to circumvent this lpc "feature" + are we disabling reset by mistake!??? + +? http://www.oftc.net/oftc/NickServ/CertFP + generic client cert support for all net/* protocols? + +? /set filter presence xmpp:xxx@yyy als user-befehl + (see METHOD FILTERING -> CHANNELS) + +? allo would like /giggle etc to show up as ctcp action + let's try channel notice first + +- _request_circuit_shutdown isnt issued or doesnt arrive + or is the disconnected-detection buggy? + +- new bug: psyc "dialbacks" - apparently it doesnt find the tcp back + seems to be an issue only when the incoming and outgoing hostnames + aren't the same - still, psyced used to figure that out.. + ... seems to be related to dyndns + ++ xmlquote vars at psyctext rendering time instead of guessing which + vars to quote in mixin_render:msg() + +- as long as people have dead host friends in their data, psyced keeps on + trying to connect those hosts. better _failure treatment is one side of + the medal, but muve should also be more aware of hosts it has already + given up hope about (and maybe wait for something more personal like a + _message to trigger a retry.. or downgrade the host to udp delivery). +? maybe disabling udp-for-notices wasnt a smart idea after all!? + it was supposed to make debug life easier, but maybe that's not true + +- invite-only places: does a double /invite uninvite people!? + +- NEW_UNLINK: place and v("place") aren't in sync (new changes for psyc clients) + +- what to do when hosts talk faster then we resolve them? + see around _error_invalid_host_slow + +? spam by unregistered users: limit unregistered users to 1 per minute for now? + or force them to do web-based registration? or even.. trustee-based? + it's the real thing.....! + +- net/irc shows objectname instead of nick for actions coming from lynx + (maybe because lynx sends a _nick_local while others don't) +- _notice_action is not shown as /me (neither in IRC nor in XMPP) + +- remote /invite is shown on irc without uniform, just #nick_place + +- do not send revision with every cast + +? current privilege model sux: + qAide(), qOwner(), boss(source), v("topic-user") + .. how does this fit with confctrl, _duty and qAllowExternal? + .. and in some cases you just want to check for isMember + .. for async entrance operations we need to separate entrance checks + from actual inserting of the user + +- in http://about.psyc.eu/Talk:Presence kuchn says announce() is not working + +? relaying für die eigenen clients geht nicht, sagt fip + (speziell xmpp: von psyc client aus) + fippo sagt eigentlich, dass net/psyc strohdoof ist und alle uniforms + behandelt, als waeren sie local / relativ + (works for localhost clients now, but that's certainly not enough) ++ proxy/relaying in wikinotify etc einbauen? + ++ we could use better integration of availability + because right now CACHE_PRESENCE doesn't work + +- filter strangers is off by default, but we still seem to get a warning ++ we should put _trustee into messages to strangers, so we can talk with + people who we have friends in common with, by default. *TRUST* + +- on psyced.org private msgs submitted by psyc clients sometimes + end up at lynX. just like that. + +? is it a good idea to use SIGS in user:cmd, too? not sure!! + +- experimental rename fails sometimes: + Attempt to rename to existing object '~nautilutz' + +- don't show "lynx loggt aus." for each and every place! + .. hmmm doesn't happen on leech +________________________________________________________________________ +== psyced 1.0 ========================================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +LIBPSYC (basic rendering/parsing.. fix in LPC, or rewrite in C?) +- parse.i erlaubt es den begrüßungspunkt wegzulassen wenn man + stattdessen ne leerzeile liefert. aua +- /invite's can get lost because they are transmitted by UDP unless + there is a circuit already +- _tag* and other MMP vars should be in MMP ++ UNI/UNL Routing as suggested in http://about.psyc.eu/MMP + +REMOVE NICKNAMES FROM PROTOCOL ++ remote uniforms could be passed around in the psyced as parse_uniform + arrays rather than as strings. this opens up the possibility to have + a stringprepped+lowercased version of the uniform for comparisons. + also this could be used as a key in a general hash of known remote objects + avoiding unnecessary parsing and ensuring uniqueness of such arrays. + doesn't that also mean we can compare remote users simply by comparing the + array pointers? and if so, does it mean we don't have to differentiate + between objects and arrays when comparing identity of two entities? + in fact - we already don't need to do that for strings either - thus + if we want to introduce arrays instead of strings we must ensure we can + compare them without an extra objectp() distinction. ++ this also allows us to REMOVE ALL _nick VARS and extract nick from uniforms + +PRESENCE STATUS ++ all _status_person need to be upgraded to _status_presence with + availability etc. +- _status_person_present appears as a chat msg for local jabber/server users. + probably best to do the new _status_presence thing and fix this en passant +- presence rewrite problem mit lastaway + 12:48 !ve.symlynx.com Du sagst noonee: hmm + 12:48 !ve.symlynx.com Anwesend: noonee ist immer noch sichtlich verwirrt.... + 12:48 !ve.symlynx.com Du sagst noonee: oook + 12:48 !ve.symlynx.com Anwesend: noonee ist immer noch sichtlich verwirrt.... +- dexter fragt Dich: So, why does your client tell me "lynx is psyced!... " every time I send a message? + net/jabber/user should be filtering _status_person_present +- da scheint ein template zu fehlen für irgendeine neue oder alte presence msg: + net/jabber/user#whojarr embee is a roving piker. +* see also various PRESENCE boxes + ++ change of nick/identity / account deletion & transfer / redirection services +- _redirect doesn't work for irc clients ++ /set redirect temp|perm in usercmd.i for users + ++ fix up packet ids for apps that need to weed out dupes + packet recovery is a whole different pair of shoes, not considered now + but related to the big DECENTRALIZED STATE issue rather +? fippo suggests that keeping member lists in sync by revisions + is useful even when we have packet ids in place.. some places it's okay + to lose packets if at least the member lists are in sync + ++ FRIEND_ECHO ... send echo for /fr type commands from recipient + not from own UNI (see #ifdef FRIEND_ECHO) +________________________________________________________________________ +== TOP DELEGATES for 1.0 =============================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- socket disconnected: ? handle remainders ? handle expected socket shutdowns ? + +- bartman sagt: psyconf erkennt keine absoluten pfade bei _path_PEM_key und _path_PEM_certificate + +- minor paranoia thing: + move archetype.pl and profiles.pl out of the sandbox + Makefiles are a threat, too.. + +- exposed lists aren't properly sort by expose level. a maximum expose should + automatically put a friend or group at the top of the profile list etc. + the logic is wrong. + +- remote idle times are still being shown in seconds + +- world/static/index.html should be generated to contain applet port +- fix member list in applet +* see also APPLET, ANNOUNCEMENT, JABBER, FILE TRANSFER + +- el: und irc bekommt keinen join fuer den raum + welche? bei newsräumen ist das richtig so + .. obwohl? überhaupt keine bestätigung!? + ++ login message that tells you about amount of pending/offered friendships etc. + ++ Fix the /surf HTML code, see http://about.psyc.eu/Talk:Style +- /surf auf fippos async umstellen +- /surf von xmpp: klappt nicht mehr, es fehlt der _tag + (schade weil es ja sogar die bilderschen zeigte.. ;)) +? wie wärs wenn vars von _request* auch befehlen zur verfügung stünden? + ... tun sie im neuen SIGS modus! + +- "Store Changes" in scratchpad using https: doesn't always work (even tho + it is a GET, not a POST) - maybe this affects other uses of https as well? + (currently disabled) + +? new common website navi? ... noonee macht schon die grafik.. super! + wiki integration. http://about.psyc.eu/Development_Tools +? builtin Website des MUVE ausbauen? + +- registering target xmpp:lynx@ve.symlynx.com isn't working. psyced + reconnects by xmpp, then switches to psyc every time + +- remote invite doesn't work for ircers.. at least on gaim + beta's lynx invites psyc://psyced.org/~gynx into TEST. + gynx thinks it has to join #TEST on psyced.org, not on beta. + +- gino75 schließt mit Dir Freundschaft. + why does it show account name instead of alias? (gmail) + +- cp person/user.o person/usercopy.o should safely create a new user + "usercopy" as it used to do, but current muve accepts the v("name") + even if it doesn't match the login name. +- involuntary lowercase: /set name wirkt nicht. ich heisse immernoch "lynx" + +- flood control over psyc - context-based? parser-based? +- message size control? how does this interact with trust? + +? should _silent rooms say hello when entered manually? + an irc client doesn't get _any_ response. an irc client could in fact + receive any sort of join notice even on subscribed entry. + since it is legal on irc to request a topic of a place you aren't on, + we can simply send topic (332) for subscribed places. + then again some topics are too long, so maybe only on manual entry + +- move templates from source code into default/en/plain.textdb + .. maybe write an automation to do it? they're just too many! + +- convert place:cmd's to SIGS where trivial + ++ add _request_do for user:cmds where trivial + ++ in the spirit of http://en.wikipedia.org/wiki/Test-driven_development + insert plenty of ASSERT() checks to make sure every software module + does what it should, and only that. See also "See also" and + http://en.wikipedia.org/wiki/Test-driven_development#External_links + http://en.wikipedia.org/wiki/Agile_software_development + inspired by http://programm.froscon.org/2007/events/42.de.html + +? should rootMsg move into net/root finally? certainly needs a merge +- when rootMsg receives a message for a uniform that was probably intended + to be different (like psyc://psyced/x instead of psyc://psyced/@x) we + should generate a Malformed uniform warning +- when rootMsg receives unexpected messages we should return errors as + they are helpful to client coders who just got something wrong. +- rootMsg should understand _request_version + +- i was just testing for irc.. but anyhow, when a user tries to deliver + something to psyc://beta.ve.symlynx.com/~lynx@psyc it should result + in some decent error from beta, not try to resolve 'psyc' as a hostname + +? /eject command that throws everyone out of a place - like a reload or + restart used to do in the past. just in case you need to fix your + member data...? + +- the /kick sendmsg doesn't show up at the kickee's (makes it nastier + than planned) +________________________________________________________________________ +== MINOR DELEGATES ===================================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- html code for manual pages should render better on mozilla (indenting error) + (fixed on access.fmt - TODO on rest). dabei muss der in die zeile + genommen werden und mit abgeschlossen. automatisierbar!?? ++ the old html code needs to be replaced by the kind that can be styled by css ++ find a way to generate manual from wiki? ++ generate help pages tuned to the needs of the user? + (consider scheme, operator status and the like) + ++ gateway email services (alerts etc) into mailcast places? + run some gateways of that kind on psyced.org? or elsewhere? + +- /log 9999999999 produces + Numeric overflow: 1410065407 *= 4 + +- for irc whois _groups should be output using RPL_WHOISCHANNELS + (groupsexpose) + +- psyc/circuit:greet() reports all protocols w/out checking ports.h + ++ _notice_invitation with a _tag could allow other entities than the + explicitly invited one to follow suit + +- optimization: psyc/parse is resolving the incoming hostname for each single + message.. this is wrong. resolution is enough once per tcp link (unless + of course the other side is presenting us a new hostname..) + fip suggests to cache connected hosts in sAuthenticated() + and delete them again on connection shutdown. + +- /silence conversation doesn't filter /action + ++ always requested by the channel inhabitants on traditional IRC: + private gatebots for one user only - transport style... + +- /set color #000000 kind of 'fails' since hex2int("000000") is the + same as hex2int("red"): zero. return -1 for non-hex? pretty logical. + +- history export doesn't show masquerade nicknames + in fact.. masquerade nicknames aren't shown in most output forms + especially not for remote users + but they should, everywhere except for irc maybe + ++ install.sh sollte lieber mit bereits ausgepackten tars operieren + können damit man darin tweaken kann und install nochmal anwerfen kann + ... geht bei psyclpc, aber nicht beim psyced + +? generate psyced without cvs support if no cvs installed? + +WINDOWS DISTRIBUTION +? how can we compile SRV into erq.exe? do we care? +? which open source installer for win to use? +? what to do about psyconf.. include perl or re-implement psyconf for win? + +________________________________________________________________________ +== OTHER MAJOR TODOS =================================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +? 420 added place profiles for psyczilla! reorganize listDescription() ? + +- warum wird eine mailto: uniform durch legal_name() gejagt? + /m mailto:kuchn@kuchen.dre.am moin. + Filter: kuchn_kuchen_dre_am empfängt keine Nachrichten von Fremden. + Du sagst mailto:kuchn@kuchen.dre.am: moin. + kuchn_kuchen_dre_am ist nicht registriert, wird daher nicht antworten können! + +- restart mechanism is broken - doesn't save .o files in time etc + betrifft nur user (oder nur mich) .. räume sind aktuell + ++ redo QUIET_LOGIN as other default of /set greeting auto + +? apply more TAGGING (tagged callbacks also avoid the monster switches) + +- ircinvite() crashes when given wrong arguments + + /lusers shows: There are 441 users on this server. + no, this is not a number from smtp spam links. +- either we keep an extra counter for people who are _really_ online + or we avoid summoning people just to hand them out a _notice_presence. + the latter makes sense really. +- also, offline users are never unloaded apparently, so the problem is + somewhere in the reset() or clean_up() procedure. we first need to + unload them, then we can look into not loading them in the first place + +TRUST1 +- _request_circuit_trust needs to check some challenge, or it can be + tricked by replay. so for now only use it over safe networks!! +? generic SASL for xmpp, psyc and irc? +TRUST2 +? TRUSTED_HOSTS are permitted to relay, this allows all users from that host to + relay.. not so cool. ++ the trust implementation needs to learn to distinguish host trust and + person trust, yet understand the interaction and develop maths for it + +SCHEMES AND SERVICES ++ allow for icq: rather than xmpp:XXX@icq etc. ++ implement *.service.* and *.scheme.* etc according to + http://about.psyc.eu/Directory_Service - so that mailto: works for any server ++ move the .psyc.eu suffix into a #define ++ implement forward-to-mailto-when-offline as a generic forwarding feature + +INVITE & FOLLOW ++ /set follow all|friends|none + allow your friends to invite you (and make you follow) into a room + so that they can immediately start talking to a group of people like + in a cc: mail without them having to be physically present at first ++ then again, why not just let _trust decide if your friend is friend enough? +? AUTOFOLLOW by CHANNELS? + consider however, that once channels are available, you can always + create a subchannel of your self context, containing only the friends + you want to have a conversation with, and poof you can start talking! +- invites von remote für remote (goodadvice/~fippo an psyced/~chr nach @psyc) + werden nicht als lokal aufgelöst + ein follow führt dazu, dass die person im nichts landet... + someplace @> «psyc://goodadvice.pages.de/~fippo» fippo lädt Dich nach psyc://psyced.org/@elsewhere ein. + /f + brain <> + +- ok, x@y notation sollte mind. dots im host überprüfen, + wenn nicht sogar leading # + In BuHa fragt el_presidente: inseln? + In BuHa fragt el: schonmal /join #fluppdiwupp@ircnet versucht? + In BuHa fragt el: oder /join #buha@euirc ? + C:xmpp:ircnet · ircnet does not resolve + C:xmpp:euirc · euirc does not resolve + In BuHa fragt el_presidente: was soll da passieren? + +- improve handling of "Minusport" outgoing stuff: + reject and handle _failures +? suspend flag on error? like this: when you receive errors, that a user or a + host could not be reached, then the castmsg'ing entity could flag this + candidate as 'suspended' or 'temporarily unreachable' - and automatically + change this status with the first sign of life from that entity or server. + this would save friendship status and room presence across downtimes. + +? uni.c kümmert sich nicht um castmsg(), weswegen presence zurecht immer + zur UNI gehen, aber leider auch raumcasts. im falle von jabber UNRs + ist das sogar ein problem. und was ist, wenn zwei UNRs von derselben UNI + im raum sein wollen? liefern wir die UNR doch noch in einer var mit? + und wenn es um das eintragen in die members gehen, verwenden wir tatsächlich + mal die _location statt der UNI die im source steht? + +- fehler im _echo von messages mit _action, da sollte 'lynX zuckt' stehen. +fritz ~> :zuckt +fritz: fritz zuckt. + active.c zeile 247.. müsste man da vars neu zusammensetzen mit + _nick_target usw? oder sollte einfach irgendwo vorher ein copy() hin? + das betrifft sowohl jabber als auch remote psyc + fippo: TAGGING koennte dieses problem bald loesen + wie denn? was würde reply() anders machen? + +PRESENCE +- eigene mood & availability erscheinen nicht im showStatus + (description schon, aber das war's noch nicht) +- irc access receives _status_away notices for each message they send to a + local away user. shouldn't it be only one? nei asks if it could be a + regular irc away code. +- detach attach offline online etc. cmds undocumented as yet +- _request_status_person receives no availability, desc and mood +? dont send presence info to strangers + sollte nicht sein + man kann _request_status oder sowas senden, und kriegt antwort +? dont accept presence info from strangers + man kann eine passende _notice machen und wird sogar als friend gelistet +- persistent_presence does not store description and mood + + gmail hat irgendwelche anderen probleme... +- heute nachmittag stand auf dem schirm: + asktav schließt mit Dir Freundschaft. + TAV möchte mit Dir Freundschaft schließen. + bin mir ziemlich sicher, dass es keinen lokalen asktav gibt.. es handelt sich + um eine fehlerhafte doppelte darstellung vom TAV alias ohne sein @gmail.com!? + einige stunden später: + Du bist mit asktav bereits befreundet. + TAV möchte mit Dir Freundschaft schließen. + ? mir scheint das passiert nicht mehr.. + wenn "bereits befreundet" ausgegeben wird, geht auch ne textmeldung an + tav auf gmail raus. eine die es in jabberland nicht gibt. das wär okay + wenn wir keinen bug hätten..... + * also eigentlich sollte da ein "meinetwegen bist du subscribed" rausgehen + weshalb wir nur noch das display an unseren user unterdruecken muessten + hier ein ausschnitt aus der rawlog.. + +» S:xmpp:64.233.166.129:-26112 +« C:xmpp:gmail.com + + +« C:xmpp:gmail.com + + ..man beachte, die newlines nach type='subscribed'/> wurden scheinbar + wirklich gesendet, aber vermutlich harmlos. dass gmail einen subscribe + abschickt für jemanden mit dem man schon längst befreundet ist, dass ist + wohl das problem. vermutlich ein dirty hack im umgang mit herkömmlichen + jabber servern welcher bei uns aber doofe effekte hat. was tun? genau + genommen müsste man errors zurückschicken, aber das wird die gmail-user + nicht glücklich stimmen.. sonst? einfach verwerfen? na gut + ... hmm würde es reichen dafür ausserhalb des switch display=0 zu setzen + und nur im fall von PPL_NOTIFY_PENDING display=1 einzuschalten? + * man sollte wirklich mal von wem kompetentes auf gmail-seite den + subscription state checken lassen. ich vermute, die lassen + gaim-b0rkedness raus in die welt. +- ouch!! ganz schlimm.. es ist kein gmail-only problem! + wenn ich mit Alias: xmpp:symlynx@jabber.ccc.de = JYNX /friend mache kommt: +symlynx schließt mit Dir Freundschaft. +JYNX möchte mit Dir Freundschaft schließen. + immerhin funktioniert danach alles trotzdem. + das ist nen alias-problem das schon laenger besteht. genauso zeigt + net/irc manchmal noch nicks statt uniforms an. + +- C:xmpp:jabber.ccc.de Invalid Packets Recieved nach: + + + nein, hatten wir noch nicht gemerkt + + + + Recipient Is Unavailable + + + anscheinend wird dieser error nicht verarbeitet und löst einen runtime + fehler aus welcher auf dem jabber socket zum abort führt (warum ist ldmud + immernoch so doof runtime fehler auf sockets auszugeben!??) - leider ist + das entsprechende debug nachm reboot weg. der error sollte als + _failure_unavailable_recipient an den place durchgereicht werden, welcher + den teilnehmer dann kicken würde. + +- is pop3 still working? i'm getting funny auth problem (hello async) + +- fip: el's weggang wurde dem fippo auf dem lokalen server gemeldet + notiz: manchmal wird der weggang sowohl an den lokalen als auch + an den remote fip rausgecastet. soll aber nur an + remote fip. + interessanterweise passiert das nur beim weggang, nicht + beim ankommen. potentielle datenstruktur-korruption? + passiert uebrigens nicht nur beim weggang. + +- falls /set entersilent off so erhalten bleibt, dokumentieren + +PERSISTENT CONTEXT SLAVES ++ the next step after CACHE_PRESENCE: don't cache it in the end users, + cache it in the cslaves - also do so for _state in general so we can + keep profile data (PHOTOS!) of people in their respective cslaves + rather than have them multiplied all over the local usership. + yes, we need those photos (miniatures at least) for html friend lists + +PROGRAMMABLE USER IDENTIFICATIONS ++ fippo insists on the uni/client split.. read also 'person.gen' below + (and saga has been asking for years) + +WHITELISTING & BLACKLISTING on the SERVER TRUST WEB ++ enable the #ifdef such that dialback from new hosts is not automatically + replied to, but a _request_trust_manual is sent to the monitor. + see also http://about.psyc.eu/Talk:Encryption +? the admins have a new '/server trust' command to whitelist a host ++ just because a cert tells us the server is who he is doesn't mean we like him ++ manual whitelisting triggers a server-friendcast telling the network + of server friends, that a new server has been whitelisted ( _notice_trust ) ++ these friendcasts can be shown in the respective @monitor places again + and either request manual interaction from the admin ( _request_adopt_trust ) + or -depending on trust levels and admin settings- automatically whitelist + the host, too ( _info_adopt_trust ) ++ manual ip blocking may also be server-friendcast, or maybe only when it was + effectively applied to an ip and threw somebody out, not the entire mask. + this uses the same methods as above, only with unfriendlier trust values. ++ again, this could cascade a blacklisting on other servers, too ++ the _info family should be used exclusively as a light form of _warn + when the server tells you about things that have happened automatically, + like an automatic blacklisting. _info_adopt_trust or something. + +CHARSET ++ ensure UTF-8 at parsing time on all inputs so we can + a) remove the action limitation: +- when an umlaut appears in speakaction, then the entire line is not + successfully converted to target charset. very weird. current solution: + speakactions are not permitted to have utf8 chars. + b) no longer necessary if we ensure utf8 input: +? use the ldmud charset features to avoid illegal codes to be output to + telnet users. +? http://spaceboyz.net/scharset.html + rede gerade mit equinox darüber. die änderung von 011 ist durch. + vielleicht wechselt er ja von SCHARSET auf SET CHARSET + +== PSYC 1.0alpha ======================================================= +THE BIG METHOD RENAME +- shouldn't all _tag_reply be renamed into the more generic _tag_relay ? + i mean.. pushback setting _tag_reply is semantically wrong whereas + setting _tag_relay makes sense. the MMP spec has abandoned _tag_reply + in favor of _tag_relay. +- methodennamen in japsyc wenigstens anpassen, selbst wenns nicht 100% liefe +? change psyc syntax for _message, move text into sth like _data or _text? + --> re-introduce _conversation ? yes! _message_behaviour is wrong +? v()storage-variablennamen global in psycige namen umbenennen + -> gut für _request_retrieve und _request_examine + schlecht für /set speakaction: wird es /set _action_speak !? ++ umwandlung der internen v("speakaction") etc in psyc-konforme + nomenklatur v("_action_speak") für einfache ausgabe an externe + clients aber auch an die textdb. ++ when thinking on how to optimize method names do also read through + all of the method parsers (msg() funcs, but also perlpsyc etc) and see which + methods should belong to common families in order to simplify parsing. ++ also make up a masterplan (on a wiki page first?) on how to name all the + #define's used in psyced, several of them going to get used in local.h etc. + even if psyced.ini makes this a little less dramatic. oh yes, the defines + should have the same names as the entries in psyced.ini if equivalent. ++ after /unsub and /unfriend we should also have /unset + +COMPACT METHODS and KEYWORD INHERITANCE +nothing can be as fast as fixing the method inheritance at psyc parsing time. +since we have to patch compact methods into long methods anyway, we know all +the methods the muve can handle - so we can handle inheritance before passing +the mc on to the core. we just provide a register_methods() for special +non-standard services within muve, and provide a way for the applications to +find out what the original mc was (mostly needed for link forwarding to +clients). example: + lynx blurbs: also der parser kennt npp => _notice_person_present + lynx blurbs: sollte _notice_person_present_at_all oder npp_at_all eintreffen + lynx blurbs: merkt der parser, dass der muve code das nicht kennen wird + lynx blurbs: und korrigiert das herunter bis zum _notice_person_present +in fact.. we can even simplify all abbrev() calls into mere == comparisons +or switches in our muve code, because they will never be needed! + +== PSYC 1.0 beta ======================================================= +TYPE CHECKING AT PARSING TIME +- unless trustworthy > 4 all incoming vars should be checked for legal + content, like chars in actions etc.. or maybe switch over the varnames + and fix the obvious candidates.. if a method is non-standard (we will + be aware of this by 1.0) we should check each var mentioned in the body. + +AUTOALIASES & ALIASES FOR PLACES ++ /set aliases auto + use temporary aliases for people in places, + keep them in [r]aliases mappings only, not in v("aliases") + copy them over only when the user decides to have private conversation + see also http://about.psyc.eu/nickspace ++ aliases for places + we have had requests for a way to shorten or at least maintain (bookmark) + addresses of remote rooms. i wonder if we should go ahead and code it in + the next obvious way (polluting the output of the /alias command even more) + or we should look at presence/subscribe integration first (where the + distinction of users and rooms becomes less relevant). see below: + +PRESENCE FOR ALL ++ krasser rewrite und fusion von raumanwesenheit und buddylists mittels + generischer presence.. siehe auch http://about.psyc.eu/presence und.. +schwer zu glauben, wir haben heute festgestellt, dass wir subscribe, +enter leave und friends nicht brauchen weil es alles sonderfälle von +asymmetrischer presence sind. also wenn der raum die presence eines +users abonniert kommt das aufs selbe raus wie ein autojoin - nur feiner +aufgedröselt - und wenn ein user den raum abonniert, dann kriegt er mit +was mit dem raum passiert.. das is dann zwar eher action als presence +aber wegetechnisch dasselbe. subscription states und contexte sind also +die antwort zur modellierung aller kommunikationsformen in einem chat. +see also http://about.psyc.eu/subscription + +PSYC protokoll verbessern, dass implementationen einfach sein können: ++ die lookup_identification queue in place/basic ist vermutlich nicht + notwendig, da (a) clients den zutritt zu einem raum von ihrer UNI + vermitteln lassen können und (b) scripte ihre informationen für einen + raum sowieso von der UNI relayen lassen können.. egal ob die UNI eine + person oder ein $service ist. wir sollten das protokoll also in dieser + hinsicht aufstocken, damit man nicht last-minute herausfinden muss, + wer wer ist, was den raumcode brutal komplexer macht. + problem dabei im falle (a) ist das verfluchte NAT, weswegen deine schwester + sich als du ausgeben kann. aus diesem grund muss die UNL für jeden empfänger + einen authentifizierungszusatz haben - das kann brachial der (outgoing) + peerport sein, wobei der aber jederzeit auch wegfliegen kann, oder + ein random erzeugter string. dieser wird von der UNI an den jeweiligen + empfänger übermittelt, damit der ihn kontrollieren kann. idealerweise + sollte man eine protokollsyntax finden, die gleichzeitig auch die jetzigen + _tags beim _enter bedienen, auch wenn sie eine semantisch ein wenig + verschiedene aufgabe erfüllen. -lynX 2005 + anmerkung, diese auth-zusätze können einen digest-schutz enthalten: die UNI + teilt dem empfänger ein shared secret mit, welches der client erzeugt hat. + der shared secret kann selbst gesichert sein durch mehrere shared secrets + zwischen client und UNI sowie UNI und empfänger. shared secret verwendet man + zusammen mit MD5 oder SHA1, aber das ist wohl klar. und natürlich kann man + alles das auch gleich so realisieren, dass es mit public key encryption geht, + statt mit shared secrets in digests. digests sind lediglich handlicher, + aber sie würden die tatsächlichen inhalte der nachricht nicht vor mitlesenden + schützen. +? kann man die latenzeffekte von DNS auch besser berücksichtigen, und + dadurch die queues in net/circuit vereinfachen? unwahrscheinlich, aber + man könnte nochmal seinen grips drauf ansetzen. + +HISTORY ++ add timestamp search to lastlog.c, add timestamp-based /history and /log + commands, maybe remove v("new") code. then again, it's quite efficient. + see person.h for details. ++ allo fragt: lynx: what about history expiring? ++ allo sagt: yeah, and then a /history since yyyy-mm-dd hh:mm feature ;) ++ allo sagt: and a backlog_num_days feature instead of num lines +- /history erlaubt nicht nach headlines zu greppen (news) +________________________________________________________________________ +== JABBER S2S ISSUES =================================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +? http://www.xmpp.org/rfcs/rfc3921.html#substates + +- port psyced.org away from JABBER_HOST (http://about.psyc.eu/TODO) +- when JABBER_HOST is active, /me doesn't work in S2S MUC access +- neuer bug in bezug zu JABBER_HOST: + msg vonnem user kommt mit "falschem" hostname, antwort landet bei net/root. + +? _nick_local and coolname are shown, but cannot be identified + +- when sending a "whisper" to a nick in a MUC we reply with an error + code 503 with . didn't we have something to say in there? + (gaim shows an empty box) + +- when entering places from XMPP-S2S own id appears both + as "resource" and as uniform. + unscalable sagt: der fehler ist beim echo place enter und nur da + +- unscalable sagt: die web inspection messages sollten type=groupchat sein bitte + +- fake any sort of showMembers() for remote MUCs...? + or actually implement it? looks so stupid on telnet when typing +- (xmpp:jdev@conference.jabber.org/Light Lan) <-- nicknames with spaces +- When conference.jabber.org is down there is no error report about it at all + +- MUC member list may be incorrect after psyced server restart.. + we should probably castmsg all local leaves at shutdown + ++ add /whisper command and real whispering in net/place/basic. (rcpt gets + _message_private_whisper, castmsg sees _message_public_whisper.. user.c + then has to filter that out when _nick_target is himself) + this should make users of jabberMUC culture happy. +- whispering in remote MUCs: + xmpp:psyc@conference.jabber.org sagt Dir: test + would be nice to see the nickname at least.. ;) + +- joining a psyc channel from XMPP-S2S with different handle (nick) is + still causing problems + +- "asks" kommt blöd.. entweder visiblespeakaction immer, oder gar + nicht (implement visiblespeakaction in net/jabber) +- ausserdem wird kein asks erzeugt wenn jabberisten fragen stellen + +- all _notice_presence are ignored. the only way to appear on a jabber + buddy list is to be logged in when the user logs in. + +? jabber s2s: photo-element verursacht runtime-fehler + fip meint es liegt schlicht an der datenmenge, aber mir scheint + es geschieht schon beim parsen. + » S:xmpp:64.233.166.129:-55794 + » S:xmpp:64.233.166.129:-55794 + » S:xmpp:64.233.166.129:-55794 + » S:xmpp:64.233.166.129:-55794 + » S:xmpp:64.233.166.129:-55794 + das ist nur eine nachricht, dass sich das Foto in der vcard geaendert hat + dann dürfte das doch keinen fehler verursachen?!? + +- M1: apparently something in psyced's MUC implementation is making mcabber crash :( + +- wenn man 5269 antelnettet und garbage reinkippt.. dann sagt psyced nix und timeoutet + sollte er nicht sowas hier senden? + +________________________________________________________________________ +== JABBER CLIENT ISSUES (...experimental is justified...) ============== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- problem mit roster? sorry, hatte nicht beachtet was das für ein + paket ist was ich da in eile reingepastet hatte.. +- xx cannot handle friendships yet shouldn't be a +- "Accepting friendship with" is shown as server notice, too +- "Anwesend: lynx" as a server notice. what was that!? new? + aha.. jabber stellt die "redline" und ähnlichen status zur schau + beim login. aber nach welchem prinzip!?!?!? +- psyced sendet _status_present bei jeder privmsg, als wärs die redline + vom webchat + +- authing an unregistered user should not be permitted + +- auf antwortet der server mit + + +- elmex: fippo: psyced.org failt soweit ichs seh bei mir alle tests bis auf den IQ auth test. + ... Net::XMPP2 installieren und damit den muve testen? + +- + + + + + + + elmex: der error muss aussen in den iq error + + +- elmex: ausserdem geht das unregister wohl net richtig, denn + beim registrieren bekomme ich halt den conflict da. + +- elmex: nichtmal messages schicken geht richtig :) + ich schicke: von testxmpp2@psyced.org/x und es kommt als testxmpp2@psyced.org an, is das richtig? + elmex: fippo: ich geb zu, rfc 3920 is nicht sehr deutlich was das from attribut angeht bei messages vom client zum server + elmex: aber http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-03.html#stanzas-attributes + elmex: sagt das man die volle JID als from attribut nehmen soll + + send<< testxmpp2@psyced.org/x + + + 10 + + + Just a test + test body + + + + recv>> 2nd_testxmpp2@psyced.org/x + + + test body + + + +- elmex: und ich setze type auf 'headline' und es kommt type 'chat' an + elmex: 2 bugs in einer message: type und subject werden gekillt + +- elmex: fippo: discos an resourcen gehen auch nicht? + send<< 2nd_testxmpp@beta.ve.symlynx.com/x + + + 10 + + + + + + elmex: auf den disco bekomme ich 0 antwort + elmex: testxmpp@beta.ve.symlynx.com/x bekommt den nichtmal + fiPP: wir mögen resourcen überhaupt nicht + fiPP: das wird alles gefiltert und vom server beantwortet + +- elmex: fippo: von subscription prozedur brauch ich garnicht anfangen oder? + +- elmex: disco geht auch nicht + fiPP: dass wir auf iq teilweise mit message antworten ist nen uralter bug + end<< 2nd_testxmpp@beta.ve.symlynx.com/x + + + 10 + + + + + + + + + + recv>> 2nd_testxmpp@beta.ve.symlynx.com/x + + + + + + + + + recv>> 2nd_testxmpp@beta.ve.symlynx.com/x + + + + + + + + +- autojoin() is disabled, so jabber clients never get to enter newsfeed + places. no news is bad news sometimes. + +- iChat sends /me with a newline after and before the /me + .. it doesn't get seen as /me, but it doesn't get output either!? + +? neulich wurde 'stanly' beim runterfahren von psi nicht aus dem MUC genommen. + als er miranda hochfuhr war er bei uns immernoch im MUC und bekam die + MUC meldungen. ob der fehler bei psi oder uns liegt, k.A. + +? wenn wir psyc die eintragung von beliebigen weiteren identifications und + locations pro user beibringen, könnte man dann diesen user via jabber + transports in seine im-logins einloggen? + +- aimgate sendeoptimierung auf #if 0 + +? ouch.. wir haben immernoch psyctext fehler: + net/jabber/user#whojarr + +- niekie entered #welcome both by telnet and xmpp. when the telnet + logged out, his xmpp client thought he had left the muc also. + ok, so the psyced did correctly handle both your identities.. only that your client interpreted the other you leaving as you leaving.. kind of logical + i will ask fippo if the xmpp-you can be assigned the full xmpp url as a nickname mucwise, than it shouldnt collide.. i noticed it pretends you being local, which is a lie + +- wenn ein jabber client ohne zu gruessen verschwindet, wird der user.c + erst gequittet beim versuch mit ihm zu reden (evtl tage spaeter + erscheint er also immernoch online) ++ In welcome spricht mb: is there a way to turn off the welcome messages everytime someone gets connected to psyc, it is a bit irritating when you use clients like ichat who do not filter those messages into a seperate channel + +- + + + +- wenn man members eines (lokalen) raumes anklickt, geht ein query nach + #raum@host/user auf. was dort getippt wird kommt nirgendwo an, und + man erhält auch keine fehlermeldung...! + ++ lustige bildchen unter: http://public.tobij.de/res/jbugs/ + die bilder sind lustigerweise so benannt, dass sie, wenn man sie + normal alphabetisch sortiert, in chronologischer reihenfolge + erscheinen. in der dirlist werden sie das per default, jippie. + da erkennt man, dass vchrizz sich mit miranda (weiß nicht ob man das + erkennt, man sagte mir, es sei miranda) auf einen psycmuve als + jabberheimatserver connected, dann einen remoteraum (psyc auf brain) + betritt und da in den raumnachrichten keine nicks bekommt. + die user im raum bekommen allerdings seine nachrichten nicht, und es + sieht für die anderen user so aus, als sei er nicht da. + eben grade hat er es irgendwie geschafft zu joinen und mit uns zu + reden. + oh, unsere nicks sieht er jetzt auch. (letztes bild) + dafür ist im pseudojabberspace irgendein wesen namens #0 aufgeteilt, + dass auch exceptions produziert wenn man es aus der kontaktliste + löscht: + 22:17 * nei sagt: .22:16:17. <@vchrizz> 13.01.2006 22:15:30 irc.onetrix.net: + EXCEPTION at line 179 of drivers/ldmud/library/library.c + (/net/library.i) in object drivers/ldmud/library/library: + 22:17 * nei sagt: .22:16:17. <@vchrizz> Illegal file to load: + 'net/jabber/user#0'. + 22:17 * nei sagt: .22:16:49. <@vchrizz> hab den user #0 aus meiner + kontaktliste gelöscht + +- wenn man beim registrierungsformular im jabberclient lange braucht um + name und emailadresse einzugeben timeoutet die verbindung: gaim glaubt + er habe registriert und muve hat immernoch kein passwort fuer den user + weswegen man genaugenommen nix tun kann...! sollten wir jabber clients + ueberhaupt zulassen ohne passwort!? + in jabber sind gaeste doch unsinn + die gaeste kann man mit SASL anonymous handhaben. + siehe xmppimpl.html, die Gäste sind dabei aber nicht in der Lage, + einen nickname zu spezifizieren + lynX muss sich das SASL anonymous zeug mal angucken, + ich kenne mich nämlich in der Benutzung der guest-flags im muve + nicht aus + +- post-0.99 TODO: jabber clients are not interactives, there may be more than + one linked client per account. + im prinzip werden sie dann ähnlich wie psyc-clients behandelt werden und + damit haetten wir eine umfangreiche spielwiese fuer das zeug + +- user.c should have a lot of common things with gateway.c and active.c + and component.c, so... inherit/include! + +- vCard ist nur für sich selbst implementiert!? + * ja, schreib halt den nötigen code um von anderen zu requesten :-) + kann doch nicht sein, dass jeder jabber firlefanz zweimal gecoded werden + muss. können wir nicht eine gemeinsame API in user und gateway schaffen, + weswegen derselbe code im jeweiligen objekt das richtige tut??? + : ich API'e schon soviel geht. aber gateway und user haben vollkommen + unterschiedliche anforderungen und so einfach, wie ich es mir in + disco.c gemacht hatte geht es nunmal nicht. + ++ xbuddylist müsste auch den alias name speichern, den user ihren buddies + im client zuweisen können + das sollte in den alias'es sein. man kann afaik nicht einen user + mit zwei verschiedenen aliases in zwei gruppen haben + ja richtig - wir sollten psyc aliases und jabber aliases + zusammenschalten, dass der roster die aliases aus psyc erhält und man + beim bearbeiten der buddies einen alias auch für psyc setzen kann. + eventuelle leerspaces im namen müssen wir dann wohl durch _ ersetzen - + scheint kein problem darzustellen. +- wenn man im client einen alias ("name" feld im xml code) setzt beim + buddymachen, dann geht der im laufe der transaktion verloren und man + muss ihn später nochmal setzen! +________________________________________________________________________ +== JABBER FILE TRANSFERS =============================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- beim versuch einen filetransfer zu initiieren zwischen zwei usern die ich + auf meinem localhost-psyced eingerichtet habe geht disco in eine endlos- + schleife, immer die folgenden zeilen ausgebend: +xmlns "http://jabber.org/protocol/disco#info" + <"iq"> <"/iq"> xmlns "http://jabber.org/protocol/disco#info" + <"iq"> <"/iq"> vars now ([ /* #1 */ + "_jabber_XML": "" +]) + kann es sein, disco.c antwortet auf jede disco#info mit ner eigenen? + müsste man da request und reply unterscheiden gehen? wie? + * disco hab ich großzügig neu geschrieben, sollte jetzt besser gehen +- nächste stufe der file transfers: bytestreams verwendet leider wieder + weswegen es nicht vom bisherigen innerxml-code erfasst wird. here goes: + +» S:xmpp:217.10.9.40:-50348 +» S:xmpp:217.10.9.40:-50348 +» S:xmpp:217.10.9.40:-50348 +» S:xmpp:217.10.9.40:-50348 +» S:xmpp:217.10.9.40:-50348 +« C:xmpp:jabber.ccc.de < +/iq> + + (a) man sollte genereller aus allen seltsamen switch-lagen herausbreaken können + und zum defaultfall innerxml kommen. wenn das falsch ist kann man ja + stattdessen returnen.. + (b) oder wir behandeln alle nachrichten die an eine resource gerichtet sind + mit dem innerxml code - können bei der gelegenheit auch das problem mit der + resource fixen. so sollte jabber routing ja eh funktioniert. gibt es einen + haken? muss muve an irgendeiner stelle für den client sprechen? + fippo: nein, nicht wenn die nachricht an eine resource gerichtet ist. + lynX: doch, es gibt exotische sonderfälle weswegen die stelle im gateway.c + die ich mit JTRANZ markiert habe *doch* falsch ist, um die entscheidung + zu treffen. schalte den debug an und schau lang genug zu. irgendwann kommen + dinge die der muve leider doch parsen muss um sie für psyc/irc/etc + aufzubereiten. ein gateway muss nunmal mehr tun als ein einfacher jabberd. + daher ist option (b) falsch und wir müssen (a) ins auge fassen. + fippo: nein. psyc/irc/etc wird nie mit resource senden. daher sind antworten + an solche auch nicht legitim + fippo: nach einiger ueberlegung muessen wir eine hybride strategie fahren + im gateway.c muessen wir wie dort beschrieben (b) machen + im user.c ist eher (a) angebracht + fippo: fuer message und presence ist das jetzt im user (a) implementiert, + im gateway (b). Fehlt zum einen noch der ganze -kram, zum anderen + schlaegt die haesslichkeit von raum%chathost@xmpp voll zu. + das muessen wir zum einen loesen, wahrscheinlich indem wir psyc:// + codieren. + bei der presence ist noch ein markiertes todo, wem wir presence out + sandten und es beim logout als unavailable schicken müssen. + ich weiss dass das unintegriert ist in unsere places-geschichte, aber + so ist das nunmal +________________________________________________________________________ +== RELEASE INSTALLER =================================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +? psyclpc should be in psyced snapshot pkg.. that means changing a lot + about the install.sh and the ebuilds.. oooph +- otherwise: teach install.sh or psyconf to copy sys-includes at + installation time to ensure we always have the ones matching the driver? + ++ elmex says: ./install.sh -d(efault)/-l(astrun) to skip all the questions? + just ask? "Would you like to skip the questions and use last run's inputs?" + ++ rpms! debs! ebuilds fertig machen und submitten! + - psyced.ebuild: saga meint wir sollten conf.d verwenden statt + /etc/init.d/psyced aus psyconf zu erzeugen. formell gentooiger quasi. + ? psyced.ebuild: manpages für psyced und psyconf + ? ldmud.ebuild: manpages für ldmud und erq + BuGless meint, um von den Distributionen wahrgenommen zu werden steht + folgendes an: + + psyced muss posix-konformes kill und restart(exec)-verhalten haben + und empfiehlt 'cucipop' anzuschauen wo er strikt das von posix + verlangte mindestding implementiert hat. + + das wrappende shellscript sollte weg. + + das erste package für jede distri sollte man selbst machen, einfach + weil man selber am besten weiß was die software braucht. danach kann + sich immernoch jemand finden, der die maintance übernimmt, wenn man + das selbst nicht machen will. + ... wenn diese punkte gut gemacht sind, sprechen die features von psyced + für sich. direkt zuständige leute ansprechen. + +? in utility/Installer.pl liegt ein angebrochener ersatz für die fragestunde. + könnte nachladbarer teil von psyconf werden (-i flag), wenn es ein psyced.ini + erzeugt. das hinkopieren aller sachen und compilieren von ldmud müsste auch + noch in den Installer.pl. egal. im moment ist die arbeitsteilung zwischen + psyconf und install.sh ganz okay. +? sollten die sub.pm's von psyconf nicht eher in einer eigenen lib dir liegen + als verwirrt in utility? einfach lib/psyconf/ oder lib/perl/ anlegen? + ++ fippo meint man kann jetzt drivers/ldmud/sys vom driver erzeugen lassen + lars meint: + 'make install-headers' zusammen mit dem --includedir Option von configure. + +? warn about running psyced/psyclpc as root? +- ensure /bin/sh is in /etc/shells. some braindead linuxes don't have it. ++ install.sh: runtime output should offer (console|buffered|flushed) + as alternatives. buffered := files, but "flushed" would be the use + of the new DEBUG_LOG feature for those who need unbuffered access + to debug output (tail-f-able). +- macosx entpackt tars! + noonee duftet: COMPILING LDMUD /ls: ldmud*tar.gz: No such file or directory / ATTENTION: More than one LDMud-dir found. Skipping. + bartman fragt: heißts vllt .tgz hinten? ;) + noonee duftet: nein, nur noch tar + noonee duftet: macos entpackt's halt schon + dann muss install.xx wohl lernen auch ein .tar zu akzeptieren + -> andere lösung, psyclpc ist im psyced tar mit drin.. +- noonee duftet: configure: error: expected an absolute directory name for --bindir: +- ./install.sh: line 249: nslookup: command not found + several systems have no nslookup these days +- "LDMUD COMPILATION DONE" should check if erq and ldmud have been + compiled correctly +- on debian erq only compiles if '-lresolv' is appended. we need to + patch the ldmud Makefile for that! + +? psyced.ini is missing a multiline syntax. and how do you specify + custom #define's for your local.h? we don't. we provide a local.h. + +? should we fix WEB_CONFIGURE to act upon webgenerated.h only, + and not try to do things that psyced.ini does? + +________________________________________________________________________ +== MINOR TODOS ========================================================= +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ++ fip suggests to add the inofficial 333 reply to indicate topic editor + and creation time. http://www.mirc.net/raws/?view=333 + +- maybe we should rethink our MOTD/BANNER logic.. and create one real MOTD + file being shown to all users (at least on request) and some special for + every access. ...... or just use the textdb for MOTD. maybe we can + provide edit tools for the textdb or at least the motd. +.... then again, ircd probably needs its own motd anyway .. just leave it + as it is, but move it into local/ + +- /version psyc://psyced.org and /version psyc://psyced.org/ + doesn't work on psyced.org - localhost recognition goes ooga dooga +- on irc: + «psyc://beta.ve.symlynx.com/psyc:psyced.org» _error_illegal_uniform to 0 from 0: psyc://psyced.org is not a legal address here. + +- textc T(mc, xx) API is insufficient to properly handle psyc inheritance + and at the same time handle formats provided by external apps. fippo's + fix in net/irc/common circumvents that, other psyctext apps skip inheritance + and use psyctext("", vars, data) with data now being used as template. + +? allow admins even if LIMIT_USERS is reached? + +- the DEALIAS() macro is incorrect. can we fix it and truly make use + of it everywhere? + +- use shared_memory() for mmp_vars and maybe other static mappings + could even textc.c be simplified by going thru shared_memory() ? + ++ /nickserv drop = /unregister - stop using a nickname. but why? + if you really want someone else to use your nick, give him the password. ++ /chanserv in net/place/standard - allow for known standard functions + in non-programmed places dynamically. + check /chanserv help on various ircnets. + +- 20after4 says: I have noticed something strange related to disconnecting - if I connect to the same uni from another client, the first connection drops with the "fasten meat belts" message + +? wir fangen subscribe requests an räume ab. was wäre wenn wir die + durchlassen? könnte man damit pubsub zeugs in räumen implementieren? + * pubsub hat nichts mit subscriptions zu tun. lies mal jep-0060 + doch, lediglich dass es so viele optionen beherrscht, dass man in + psyc dazu ne hundertschaft an channels braucht. + nur was wollte ich eigentlich sagen.. dass /sub selbst ein /enrol + sein könnte? hmmm + +? hmm.. htuniform() in http/library isnt being used by anything + why did i code it then? there must be a reason + ++ METHOD FILTERING -> CHANNELS + fippo hotzenplotzt: hrmpf hrmpf. ich will webexamine setbar aushaben bitte! + lynx: programmier den ultimativen filter befehl + lynx: .. /filter + lynx: .. /filter from + lynx: und zwar im user.c - denn du kannst nicht den multicast zerbrechen mit ner pubsubbigen ausnahmeregelung *g* + lynx: im prinzip ist das ja ne verfeinerung von ignore.. ignore mit methode + könnte man auch einfach /set ignoremethods machen, welche + nur zum einsatz kommt bei sources, die im /ignore sind. ++ CHANNELS + fippo hotzenplotzt: da kann ich auch clientignore nehmen + fippo hotzenplotzt: es geht mir darum, dass ich als raumadmin teilweise nicht will, dass soviel traffic an alle geht + lynx: dann musst du channels implementieren + lynx: damit sowas seinen eigenen channel kriegt + fippo hotzenplotzt: möglich + +PROFILES +? profiles: shouldn't this be at http://psyced.org/~user ? + yes and no, since the profiles are not supposed to be shown on the + remote server - so what should we do so profiles have a nice url? +? also: should we use dhtml to allow back+fwd clicking in /surf history? + using http://codinginparadise.org/projects/dhtml_history/ maybe ++ person:qDescription : we could greatly simplify all decisions what belongs into + // the outgoing description for whom, if we introduced a psyc2trust + // mapping into profiles.gen with 'trust ' values for each entry. ++ we could add type (int,bool) and maxlen info to profiles.gen ++ we could have the web-based profile editor use these things ++ we could have it interact with psyczilla on psyc level like /surf or better ++ then again, completely different idea: we could seperate profile levels + by channels - so we have a chance to multicast changes to our profile to + the intended people and don't have complexity explosion in user data for this. + +- Invalid password error in tn/server appears indented w/o LF + ++ provide textdb editing mechanisms: ++ /template ++ web-based editor for textdb with optional directory-style navigation ++ could it be the /config command can be replaced by /template ? + +? /set identities hilft skype etc pseudo-urls unterzubringen, profiles.gen + spricht allerdings eine andere sprache und will einzelsettings. sollte + man wohl umsetzen.. oh graus! + +? sollte /set exposetime auch /who boykottieren? wohl schon +? showFriends() shows aliveTime of local objects that you offered friendship to + +? fip: ich braeuchte irgendwie mal zugriff auf nen freebsd und nen osx + und nen autoconf-guru (das bezieht sich auf den erq) + +- fix sip and start phoning away ++ alternative: implement jingle + - imho ist sip ne nummer zu komplex, die rfcs zum thema sind mehr als + tausend seiten lang. jingle sieht schöner aus, vor allem + haben wir da das generelle framework schon + +- re-connect eines telnet erhält echos aller re-enters +- ähnlich viel zu verbose ist der relogin nach einem /detach + ++ verbatimuniform sollte umbenannt und invertiert werden nach + encodeuniform (quoteuniform? besserer name? oder gleich strictirc?) + +- /x für bosses funktioniert gar nicht? also email ausgeben etc + +- sollte das neue lastlog-verhalten ernste probleme aufwerfen müssen wir + .99 mit UNSAFE_LASTLOG ausliefern. die art wie local stringp user gehandhabt + werden ist jdf inkonsistent, siehe viele neue TODO kommentare + ++ psyced sollte auf wunsch SOCKS beherrschen, dann könnten wir + tor verwenden als anonymisierungsdienst für connects zu den + proprietary IM systemen und hier und da auch sonst. RSS fetches zB. + ++ have redlines for different languages.. depending on who is requesting it + +? _subject in jabber messages wird ignoriert. was machen wir damit? + +library/dns ... geht derzeit sowieso nicht ohne erq. erq muss sein! +- an mehreren stellen verlassen wir uns darauf, dass __ERQ_MAX_SEND__ + undefiniert sein wird wenn erq beim hochfahren nicht gefunden wurde, + aber wenn ich ldmud mit -N aufrufe wird __ERQ_MAX_SEND__ trotzdem + definiert. was tun? ++ es gibt neue localhost selbstresolver switche, das müsste mehrere + if localhost abfragen im bisherigen code unnötig machen. optimization TODO + +- don't accept connections during shutdown sequence + should work by returning 0 from master:connect() +- reorder shutdown? why do we see _notice_place_leave_reload_server + messages from local rooms? and why do we see every single person + leaving from somewhere? this should all be quiet at shutdown + at least for telnet +- the new shutdown sequence erratically reloads rooms that have already + been destructed. they need to be shut down after all the user objects + have quit them. test: put an #echo into a room you use, like tuxedo.c + +? junctions könnten nen /trace befehl anbieten um das netzwerk aufzuzeigen + +- question recognition: check if following char exists or is whitespace + to avoid acting on urls + +- funny log of the day: + «xmpp:base@conference.jabber.org» base sagt Dir: You have been invited to the base@conference.jabber.org room by t@jabber.berlin.ccc.de Reason: None given + > /reply + Beginne Privatgespräch mit xmpp:base@conference.jabber.org. + xmpp:base@conference.jabber.org ~> sorry, mucs in jabberland are not supported from psyc + xmpp:base@conference.jabber.org ~> it would be a technically berserk thing to do + xmpp:base@conference.jabber.org ~> so it only works the other way around + Privatgespräch beendet. + PSYC @> Du sagst xmpp:base@conference.jabber.org: sorry, mucs in jabberland are not supported from psyc + Du sagst xmpp:base@conference.jabber.org: it would be a technically berserk thing to do + Du sagst xmpp:base@conference.jabber.org: so it only works the other way around + "xmpp:base@conference.jabber.org" ist nicht erreichbar. + "xmpp:base@conference.jabber.org" ist nicht erreichbar. + "xmpp:base@conference.jabber.org" ist nicht erreichbar. + schöner wärs, wenn wir nur eine _failure erzeugen würden beim fehlschlag einer queue.. + reicht ja wenn net/circuit ein temporäres mapping of mapping of sendern & empfängern + anlegt und jedes paar immer nur einmal vertröstet... oder wir machen eine kumulative + nachricht? msg[source] .= ", target\n"; in der alle von diesem circuit betroffenen + targets auflegistet werden.. + ++ htmlhead(), htmlpage() und htmltail() [see net.h und http/header.i] + allow for keeping state of html head/body and the need for a footer + independently on how many htget() functions are called and feel + like contributing something to the output. header.i could even attempt + to do a nice multi-column rendering of all outputs it gets, if we also + add a htmlwrite() macro. + +? müsste man das eigentlich auch erlauben? mit xmpp: geht es jedenfalls + /m jabber.ccc.de/Echo janz gewagt + "jabber.ccc.de/Echo" ist nicht erreichbar. + +- wenn der muve beim aufmachen einer connection auf den + _notice_circuit_established warten würde, könnte er wenigstens wissen, + für was ihn der andere hält (host/ip im _target). + perlpsyc macht das und wir erlauben eigentlich auch nur fire&forget + scripten ein anderes behaviour. wieso nicht auch beim muve??? + +- kein exec() mehr von server.c nach user.c - stattdessen beliebig viele + logins pro user.. telnet, irc, und jabber mehrfach.. alles erlaubt. + obwohl, das ist wahnsinnig haarig mit den custom user.c's pro protokoll.. + dann müsste man net/prot/user.c von net/user.c entkoppeln damit mehrere + prot/user koexistieren können.. aufwand! + +- Dropped a packet from 83.243.42.81 trying to relay for 83.243.42.81. + Stattdessen, wenn ip==ip: "Dropped a packet from %O which does not resolve." + und die connection verabschieden mit einem _error_invalid_host_none + "Sorry, for reasons of aggravated paranoia we cannot talk to you as long as your IP number does not resolve to a hostname." + +? warum können wir keinen ICQ gateway einsatzbereit 24/7 haben? ++ sicherstellen, dass icq:XYYY syntax netzweit gültig ist + (wird auf icq.scheme.symlynX.com gemappt und durch brain geroutet) + +- von psyc eigene xmpp-jid ansprechen führt dazu, dass muve xmpp mit sich + selbst redet. lustig, aber unnötig. + könnte da nicht compile_object das abfangen? quark, das erledigt xmpp_sendmsg +- lynx@psyced.org geht nicht, weil er dann per default xmpp macht und + psyced.org beschwert, dass man nicht den JABBER_HOST verwendet. autsch! + +- noch ein problem mit JABBER_HOST: wenn man auf einem remote psyc server + ist, dann wird /invite xmpp:person nicht mit dem JABBER_HOST abgeschickt, + ergo funktioniert der invite dann nicht. + +? neue negotiation-ebene mit zero-source paketen +? "_using_modules _encrypt" zum starten von TLS + wie geht das nun? zwei muves können sich hochschalten auf TLS? + klappt nur leider nicht, weil einer von beiden sich als "client" begreifen + müsste? wie isset? interserver tls müssen wir also weiterhin auf die lange + bank schieben, wie? + ++ /show-liste alphabetisch? + +- slight sane_quit bug (w/ quit(2) && keepUserObject() == 0) + +- wenn eine user-connection disconnectet wird man gleich gequittet inklusive + announce-broadcast. wir sollten da einen zeitverzögerten "stoned" + mechanismus haben, damit keine dümmlichen announces rausgehen. + ++ /fr ohne argumente nimmt die letzte freundschaft an? (aber nicht persistent + speichern) + +- news.c: javascript-links herausfiltern und ignoren. beispiel: +(TagesschauNews) DFB-Pokal: Hannover und Schalke wollen Gas geben +javascript:popnoresize('http://sport.ard.de/php/sportticker/?event_art=6&ticker=467&e[]=2463&e[]=2464&e[]=2465&e[]=2530', 375, 600); + +- net/jabber rendert cvs+wiki notifies etc mit origin-uniform, das sollte + hübscher darstellbar sein.. noch damischer: web notifies ersheinen als hätte + man sie selber gesagt!! + +- friendships: habe gerade nen local user in meiner statusliste, der + gar nicht online ist sondern mir einfach nur nachrichten hinterlassen + hatte.. und ich bin frisch eingeloggt.. der typ is nich da! wie kommt + der da rein?? +? use -DEXPERIMENTAL to debug + ++ spoof tester script in perl- oder pypsyc, welches gespoofte oder fehler- + hafte meldungen zu erzeugen versucht um w() und co dicht zu kriegen + +sollten wir wieder eine "Too deep recursion" im raumbereich haben +könnte es ein fall sein für diese kleine vermutung: + wenn QUIET_REMOTE_MEMBERS nicht defined ist, ist + isValidRelay(vars["_source_relay"]) in place/basic.c:47 bei einem + _failure_unsuccessful_delivery true, weil im _source_relay der + raum selbst steht. und dann so weiter, da der user nie aus _u + verschwindet + ++ support for transfer/sharing of user data between servers. when a new + server is started using the .o files of an existing server, each loaded + user object should be aware, that it is *not* the entity that *made* + all of those friendship arrangements, by comparing its current uniform + to a stored v("identification"). then it should warn the user and disable + all delivery of presence to remote entities until the user either switches + the identification or reorganizes his friendship data. tricky tricky. + +? handle http proxy requests in whatever way (for proxyscanners etc) + saga sagert, er hat das schon getan? + +- bei gelegenheit eines der beiden sendmsg() global umbenennen und + das library_object() rausoptimieren. + ++ virtual hosting/vhost/CNAME support: allow UNIs and rooms to choose any + CNAME pointing to our server: we need a very elaborate way to figure out + what uniforms are local or remote, and DNS helps us find out what our + CNAMEs are. in the end /set identification either defines a person's + wish to be addressed, or indicates where its reference account lies. + - how are you planning to keep dns and local settings synchronized? + + hmm.. send v("identification") thru dns lookups before using it? + +? change httpd in a way that it intercepts scriptkid attacks nicer than + trying to intantiate ridiculous objects? (no extensions outside static?) + see also http://about.psyc.eu/Web_Attack +________________________________________________________________________ +* GOTCHAs +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +! When the /topic command makes funny errors, then your room has a custom + cmd() and doesn't pass vars over. It should use ON_COMMAND instead! + +________________________________________________________________________ +* TOYS IN THE ATTIC +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- In welcome spricht Igramul: hmm... the "+list" command made xchat crash + man sollte dazu sagen, dass er danach gesagt hat, dass es ein + xchat-bug ist. irrelevant fuer UNSER ctodo + ... mag sein, aber man könnte trotzdem nachschauen was da passiert, + und manchmal findet man heraus, dass man doch selber was falsch + gemacht hat und alle anderen clients lediglich nix gesagt haben.. + +- http://about.psyc.eu/Remote_join_heise_from_beta_dump noch aktuell? + noch relevant? kuchn schmiert: dunno. verwende kein _request_enter mehr + +- 15:38 -!- psyc://goodadvice.pages.de/~el [psyc://goodadvice.pages.de/~el@goodadvice.pages.de] has joined #psyc://psyced.org/@welcome + ich hab nen alias auf remote-el, vielleicht kommt es daher + der ident sollte in jedem fall nur "el" sein + ... ein sonderfall für den sonderfall? was änderts? wen kehrts? + +- apparently clients can _link multiply and even join rooms multiply, + but the side fx will not be nice + +- fippo meint es müsse ein replyvars-handling her. der eingriff wäre aber + ziemlich dramatisch.. lynX vorschlag: die msg api müsste dann so aussehen +mapping rvars msg(source, mc, data, vars, rvars); + showingLog würde rvars["_INTERNAL_flag_showing_log"] werden + das heftige daran ist, alle sendmsg() aufrufe in allen entity-derivaten + (siehe http://about.psyc.eu/Psyced msg flow) müssten die zurückgegeben + rvars auch benutzen. dafür fällt das hässliche entity:sendmsg() weg. + wenn ein msg() signalisieren will, dass die nachricht abgearbeitet ist, + gibt es return 0 statt return rvars durch. ist das alles, oder fehlt was? +________________________________________________________________________ +* GATEBOT / IRCGATE / etc +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- msg from irc to remote psyc user doesn't work: + ERQ could not resolve "symlynX". + (it tries to resolve the irc:nick) + +- MAUR: psyc dont send jid disconnect on nickchange and/or quit? +- reconnect? +- MAUR: I set a crontab to HUP ldmud ++ enter channels? + +? provide CTCP PRESENCE ++ relay "no such nick" properly ++ version() send *my* version info + +- ircgate echot nicht, weder dem ircer noch -was doofer ist- dem psycer + evtl lässt sich das im generic für alle gates lösen, vllt auch nicht +- _message_echo sollte geliefert werden, und zwar als NOTICE + +- irc.at.caudium.net begrüßt mit NOTICE AUTH :*** Found your hostname etc. + das wird komisch dargestellt (und in die history gesteckt) als + 22:41:35 Anderswoher sagt lynx: Found your hostname + lynx ist da vermutlich einfach der eigene nick.. + +- the gatebot should inform the ircers (on the irc network) about + joins/leaves probably. the #pike'ers accept us (the gate), so for them it + would be a help. also it should disturb nobody, as PSYCgate is usually + residing in #psyc. or we just add #define DEAF_IRCERS or something like + that. ++ in fact there is plenty of improvement that can be done on gatebot!! + +? wenn gatebot an remotes spricht, dann kommt das so an: + psyc://213.73.91.20/irc:symlynx + das sollte lieber irc:symlynX und psyc://213.73.91.20/$IRC in _source + und _source_relay geliefert werden, oder so ähnlich.. hmmmm + jedenfalls muss der empfänger sowohl eine "identität" des absenders + sehen können und gleichermaßen ein /reply hinkriegen können ++ gatebot sollte _echo erzeugen, selbst wenn es unecht ist + ++ allow rich text formatting between clients who support it. since we + have no preference in that field yet, we can stick to everybody's xhtml. + +- when trying to log in "admin" net/person generates + _failure_object_create_admin, which is fine, but then + it runs into a runtime error + +- einloggen auf anderen servern + /connect psyc://symlynX.com/~symlynX + *** Sorry, this function is not yet available across the PSYC network ++ wobei es sogar wichtiger wäre, wenn man durch die gateways connecten + kann.. das würde man aber so machen, dass man mittels /set id (forward) + eine empfangslocation angeben kann wie icq:XXXX, aim:YYYY oder irc:ZZZZ. + dann muss gatebot nur noch lernen die location zu erkennen und ihre + eingaben an das zugehörige uni-objekt zu leiten. ziel der übung: jede + message an psycgate ist ein muve-cmd() und alle muve-ausgaben sind gatemsgs + +== UNNECESSARY IDEAS (brainstorming trashcan) ========================== + ++ invite-except! the idea is to be able to send an invite in a group + to join a new group with the exception of one or more people. the + exceptions should not be informed, but of course some people will + patch their servers so they can see it. still they cannot enter the + new group as they are not invited. this is not intended as a kick + strategy really, but rather as a way to organize a birthday party + for somebody etc. better ideas? temporary group exclusion? but we + cannot allow that to be invisible to the excluded one. hm actually + yes we can. and then again the whole plan is crap because with + channels we can simply create a channel of all except a few and do + not need anybody's permission to do so. ok forget this. just documenting + this here and poof forget it again. + +== PSYC CLIENT ISSUES ================================================== ++ if newbie: directly show register dialog + (lynx should add _status_unregistered or so) + +? psyc clients haben uferlose idle times + und sie altern nicht + +? cryptochat raum? + +? how to improve _request_store and _retrieve? + look at http://asg.web.cmu.edu/acap/ for ideas + ++ unbekannte schemes auflösen (.scheme.symlynX.com) + und dort nach nem gateway suchen.. +? support *.place.symlynX.com for well known rooms + +? support voice chat + look at: http://freshmeat.net/projects/pyvoicechat/ + dormant since 2004.. oops + +== APPLET ISSUES ======================================================= ++ sprachauswahl im applet?! [bart hat auf der pikemodi was gemacht hiermit] ++ anclickbare register etc links? +- wenn ein unregistrierter talkt, dann bricht der muve den /talk ab + aber applet erfährt nichts davon und behält den falschen prompt bei +- selector box erwischt die falsche befehlszeile im netscape4 +? dep's new veChat.jar does not work on IE + but some of the old stuff does.. how do we find a proper solution? + +== DOCUMENTATION ISSUES ================================================ +ich habs.. jede datei definiert am anfang in welche kategorie sie gehört.. +"library" "user" "server" "language" etc... und jede funktion kann sich +dann mit /** library: this stuff.. */ woanders einordnen.. jetzt brauchen wir +ne dokuware die sowas kann, und jemand der die dokummentare reinschreibt.. + -> doxygen-1.3.9.1.src.tar.gz (2649K)... definitiv kein aufwand, sowas... + +== RELEASE ANNOUNCEMENT ================================================ +REDIRECT: http://about.psyc.eu/Release_Announcement .. außerdem: + +? Netzeitung.de könnten man beschwatzen schonmal nen echten psyc feed + zu liefern.. am besten wenn sie einen stabilen 0.99 server installieren. + oder sie führen einfach dpa2psyc aus. + +? http://en.wikipedia.org/wiki/Chat und ff. strotzen vor Fehlern.. + erbarmt sich jemand? und ausserdem.. http://en.wikipedia.org/wiki/PSYC + man kann sich ja an http://de.wikipedia.org/wiki/PSYC orientieren :) + +- "CSpace could be the 7th, component of the open office suite, see the + discussion on the mailinglist of Open office developers for July 2006" + they must be kidding!!!! + +== COMPETITION ========================================================= ++ man könnte die kollegen bitten gemäß forschertradition unter "other + similar projects" einander kreuzzuverlinken. die meisten sind eh vapor + und würden uns daher interessierte liefern. wir stecken die dann auf + http://irc.pages.de/research. optimal ist es noch, wenn wir die vielen + denker überzeugen das bestehende psyc um ihre ideen aufzustocken. + +http://www.irssi.org/projects/irc+/overview.html +http://www.holoweb.net/~liam/irc++/ http://achurch.org/irc3/ gale.org +http://freshmeat.net/projects/boo/ + http://www.oreillynet.com/pub/t/78 + +== FORK ================================================================ +- _INTERNAL_trust einbauen +- unique counters für contexte, ergo global packet ids unterstützen + see also http://about.psyc.eu/Routing 2.2 + +- einmaliges rendern von psyc paketen ohne psycd realisieren, + idealerweise auch im sendmsg() statt in group/route, und zwar so: + // new idea: for future use, psyc packets need to be cached + // according to their packet id anyway, so whenever the _count is + // the same as the one before, sendmsg() can optimize by using + // the last cached outgoing packet of this context. this way the + // render-only-once optimization can move down into sendmsg() + +* das problem der dangling delivers bei destructeten psyc servern. +- die drittbeste lösung ist im begriff abgeschafft zu werden: + psycd ist allerdings noch nicht vollständig ausgemerzt +: die zweitbeste lösung macht FORK derzeit mit psyc_deliver() in der lib ++ die beste lösung wäre psyc/server und active.c wieder in ein + gemeinsames circuit.c zusammenzuführen. der versuch mal schnell active.c + zum neuen server zu machen ist gescheitert, da active.c schon eine weile + lang server.c gar nicht inheritet. letztlich ist diese operation nicht + überstürzenswert, lieber vorsichtig planen - etwa in dem wir für das neue + mixgerät aus active, server und circuit erstmal ein temporäres newct.c machen + +________________________________________________________________________ +UNDER CONSTRUCTION: (offene baustellen im LPC code) +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +- file transfers between local jabber clients +- file transfers between jabber clients and gateways + +? zum thema negotiation, kann man mit demselben code auch http://www.codemastr.com/irc/draft-baudis-irc-capab-00.txt implementieren? + ++ ldap support in progress + +- #define ALIASES erlaubt nach wie vor das gesamte local-nickspace subsystem + abzuschalten. praktisch wenn man einen fehler sucht und vermutet aliases + könnten mit hineinspielen. +? müsste man ALIASES sowieso tieferlegen? von tell() nach sendmsg()? + das bedeutet dass wir überhaupt erstmal ein user:sendmsg() brauchen + damit wären wir beim nächsten eintrag: +- sollte sendmsg() lokale nicknames akzeptieren? und wie soll das gehen? + und fippo meint sendmsg() sollte die psyc nickspaces realisieren - + also aus der library heraus in die userobjekte wandern? teilweise? + kann dann wenigstens tell() weg? und die call_outs in + person.c können #'sendmsg werden? +? standard msg-API überdenken? hier ein denkansatz: +#define sendmsg(target, mc, data, vars) \ + (objectp(target) ? target->msg(ME, mc, data, vars) \ + : libsendmsg(target, mc, data, vars)) +tobi meint: sendmsg() ist nicht der ort, in dem aliases gehandhabt werden + können, wie ich sie mir vorstelle. meine vorstellung von aliases ist: sie + bezeichnen einen user, nicht einen alias. sprich: man freundet sich mit + (alias)X an, löscht den alias und überschreibt ihn und ist dann mit + psyc://.../~X befreundet (oder auch im query oder was immer), und nicht + mit dem nichtexistenden oder neuen X. + solange wie man dieses konzept verfolgt kann man die aliases nicht im + sendmsg() handeln, leider. + das problem ist, dass ich wohlwissend dass man das überall braucht ne + 2 kleine funktionen (alias(), dealias()) einführen wollte, du aber ver- + kannt hast, dass man das andauernd braucht und deswegen meintest + "da reicht ein makro, oder man macht das halt von hand", weswegen aliases + (nach bisheriger konzeption) an mir hängt. allerdings baue ich das lieber + noch in /fr und /nf und was da noch alles ist ein, als dass ich so ein + pseudoalias im sendmsg() haben will. + also: mich einfach machen lassen, ich kümmer mich, und bitte nicht so ein + alias im sendmsg() realisieren, dass dann einfach nur halbgar sein könnte. + danke. + +- in net/library gibt es neue parseURL und makeURL, die werden aber an + vielen stellen noch nicht benutzt. verschiedene systemfunktionen wie + register_target sollten vermutlich urls im neuen url.h format annehmen. + eilt aber nicht .. an einer stelle im parse.i wird zerschnippelt was + schonmal einzeln war.. da würde die URL datenstruktur helfen. + +- es sind an verschiedenen stellen noch pr()'s und S()'s aktiv + die müssen nicht zwingend ersetzt werden. eile mit weile. +________________________________________________________________________ +== SECONDARY ISSUES ==================================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ +? embee suggests a special treatment for dyndns hosts: such servers + should inform their counterpartners of being dynamic, since they + can't predict when the ISP is going to kick them (in order to + shutdown politely). lynX thinks dyndns servers simply shouldn't + promote a connectable 4404 port, maybe? then again - any fixed + server can be torn down, and any dyndns server can be installed + firmly enough, that it keeps on serving its 4404 - you just have + to make sure you don't use an old ip number - and we do that. + ++ By providing POP3 and SMTP we could actually use mail interfaces to produce and consume multiline messages, then route them through PSYCs multicasting. Nifty. + http://about.psyc.eu/POP + ++ let the SMTP server ask recipient if sender is "accepted" + so the user object can decide to do whitelisting for mails + and the smtp server can reject an email even before DATA is issued + +- smtp servers are wonderful tarpits for spammers, but do we want to keep + them up forever? clean_up() ? +- we should detect & act when we are running out of sockets!! + ++ a command or tool to inspect our own certificate? + ensure it contains our server hostnames - or even better - learn our + server hostnames from our certificate? something psyclpc should do? + +- /set clearscreen + Einstellung "clearscreen" ist nicht bekannt. +das sieht doof aus.. gehts auch besser? hmm + +- show the current command character in all usage messages (by introducing + [_command_character] or something like that) + +- /invite should do remote echo, like _message_private, not local +- places are load()'d twice.. probably both the user object doing /go and + the master object doing the clone. may be healthy to fix that. + ++ dns_rresolve should panic when discovering fake PTRs and suchlike + blacklist_report() ? :) + +SHOW STATUS? +? is the following stuff superceded by DECENTRALIZED STATE? +? _status_flags aus der auswahl _members _topic _configuration und + _limit_history bei _request_enter mitgeben, damit showStatus dann die + erwünschten _status - meldungen zurückschicken kann. die flags dann je + nach zugangsbedürfnissen einstellen (telnet möglichst nix usw.) + so ähnlich, aber besser: ++ replace _status_place by _status_description etc in a compatible way + to the person description. make sure _identification is sent in the + same way ++ "/set verbose on" gibt (unter anderem) mehr statuskram beim einloggen aus.. + +? filter + /msg: auto tmp-friend status ? + hierzu müsste man wohl einen status "bekannter" in ppl einfügen + ++ think of a way we can keep track of how strings are encoded to avoid + any unnecessary conversions.. encoding is a data structure of + (string charset, flag quoting) where quoting is XML, URL, b64.. + we probably need to add _encoding to every internal packet and + carry around big cache mappings like iso2asc["bäh"] = "baeh" + and clear them periodically. uh.. better ideas? no hurry. + _encoding applies to the body and all non-MMP vars in the packet. + +- mail notifications cause incarnation of the recipient who will be + QUIT'd a while later.. too much noise and rcpt should probably + remain incarnated longer since mails seem to arrive often enough + for some users to never leave memory. + ++ disallow TLS/SSL connections from localhost to save CPU resources + for useful things + +- re-examine everything looking for optimizations.. like, are any + lower_case's being called twice etc. or introduce a "lowercased" + flag into the driver's string structures *grin* + +? man könnte in /net aufräumen und matrix.c etc wegtun + +? do we need per-object dynamic debugging ? (a la gueldenland-debug()) + +== PSYC ISSUES 1.0 ===================================================== +? shared secrets on unencrypted circuits (does not protect against tcp-napping) +? generic shared secret authentication between psyc objects + +? legal_host für udp pakete zwex /block + moment.. bei udp kann man die ip ja faken.. + also muss was besseres her.. method filtering? + oder zwei udp partner haben nen shared secret? + oder wir brandmarken die udp-user mit dem "d" flag im URL_TRANSPORT + und erwarten von places und people, dass sie selbst entscheiden was + sie solchen fakebaren nachrichten erlauben.. dazu müssten wir aber + source nicht mehr als string verschicken, sondern als url-datenstruktur + +- raum versucht remote raum zu entern -> katastrophe? + +- psyctext() hängt sich auf wenn ein [ nicht wieder mit ] geschlossen wird + +SPAM / FLOOD CONTROL ++ connect flood protection (against icaruz from pD9E3F294.dip.t-dialin.net) + 1. introduce #define MAX_CONNECTIONS_FROM_ONE_IP + 2. warn admins via monitor when MAX_CONNECTIONS_FROM_ONE_IP * 70% + is reached + 3. block when MAX_CONNECTIONS_FROM_ONE_IP is reached + 4. improve /block to detach all superflous connections + 5. allow /block syntax to define a reduced + maximum number of connections per ipmask, defaulting to 0 + 6. maybe MAX_CONNECTIONS_FROM_ONE_IP can also be lowered + interactively using "/block * 200" +see also: http://about.psyc.eu/SPAM + +PERSON GENERATOR & MULTIPLE CLIENT INTERFACES +? one day we could also have a person.gen to create all sorts of user + objects from, but it sure is confusing that each of them still needs to + be able to call upon the various protocols.. this may either need a + seperation into user/client/access and person/identification objects, or + the needs for variation of person code is small enough that we can merge it + all together as we have done up to now, and customize it dynamically + using /set commands or web forms, which is itself a flexibility plus. + in this case a few ifs are probably better than rewriting everything for + optimized bytecode. if you want optimization you should write yourself + a UNI server in c++ anyway... ;) + +== FRIENDSNETS / FRIENDSHIP DEGREES / WEB OF TRUST TODO: =============== ++ friendivity 0 = nur meine freunde sehen mich + friendivity 1 = die freunde meiner freunde können mich kennenlernen + friendivity 2 = die freunde der freunde meiner freunde ... ++ umsetzung in /examine etc. ++ testimonials - was andere über einen sagen ++ friends und friendsfriends als gruppen/listen adressieren für newsletters ++ kontaktdaten exportieren an flat hierarchy kommunikationstools + wie palm, outlook.. ++ blogs die sich auf friends definieren ++ färbung der freundschaften - trennen/kennzeichnen/untersch. einstufen + bspweise: business contacts vs online gamer mates + vs nachtleben/dates vs richtigen freundschaften ++ private websites mittels psyc authentication plus hohen friendship degrees. ++ friends search engines -> friends file sharing ++ neuer gedanke: die neuen freunde eines freundes sind auch für freunde + interessant.. also _notice_friendship_established selbst friendcasten? :)) + (na klar, das ist einfach ein _enter im freundschaftscontext - nur sind + evtl nicht alle im richtigen channel, um den enter zu sehen..) + +== IRC ISSUES 1.0 ====================================================== +- (psyc://allo.homeunix.org/~allo) allo: hm, die userlist hier hat sich bei deinem nickchange nicht angepasst im ircgateway + saga: ja, das ist ein bug, der mich auch immer wieder nervt + ... kapier ich nich ... ich muss das reproduzieren können - also wer + bitteschön macht nickchanges.. der +alias befehl? + ++ finish IRC_FRIENDCHANNEL according to http://about.psyc.eu/IRC_Friendchannel + some people would give up jabber/bitlbee as soon as this works! + TODO: (fix) proper response on /names &, /who & and on first join. + ++ why does IRC have a regular /lusers and usercmd.i doesn't? + move it over and rename the /lu admin command into.. "/tcp u" ? + like "/tcp " for various types of list_sockets() + ++ new irc: handler (in library) to support official irc: url syntax + with irc-networks and even irc-serverhosts + +- Panic: [EPIC4-1.1.6 (338):Tried to make [#LIVE:0] the current channel of window [1], but I'm not on that channel!] + +? setting for showing mc's + +? ctcp-erkennung _nach_ 512-byte splitting (wen juckt das? -> 1.0) + +? bartman fragt: ists beabsichtigt, dass /set privatetext doppelpunkte tötet? + ja.. verwende gefälligst +set. sowas passiert durchaus mal, dass leute + /set verwenden statt +set. was machen wir da? nochmal drauf hinweisen? + ++ remove keepUserObject(user) { return 0; } and instead implement a + reconnect strategy with re-join of places etc. careful, you have to + test that all clients like the new login procedure! + +- "known bug:" die shout()-funktionen betreiben kein vars-cloning, daher ist + sowas möglich (das sollte aber nicht schlimm sein): + place/irc caught zero source ("_notice_broadcast_garbage","Test 1.",([ + "_source_hack": "c|h|a|o|s!c|h|a|o|s@ve.symlynX.com", + "_nick_me": "lethe", + "_nick": "c|h|a|o|s", + "_prefix": "" + ])) + +- login via cert? + irssi supports usage of private certificates and muve can read them. + hints for irssi: place cert and key in one file + +== PSYC AUTHENTICATION ================================================= + (see also http://about.psyc.eu/Authentication) +- man wird immer egal von welcher ip, egal mit welcher UNL geauthet ++ auswertung des IRCNAME als UNI angabe, mit entsprechenden folgen ++ authenticate() in person vergleicht jetz einfach die ip, man könnte + aber auch den user rückfragen += net/place/threads verwendet den kram abenteuerlicherweise +________________________________________________________________________ +== CHANGES for 1.2 ===================================================== +¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ++ /set logsize ? + hm ja es muss einstellbare loglängen geben für räume und user + maximalwert ist dabei abhängig von age +- person:htinfo() kann abgeschafft werden zugunsten von infogenerierung im + webserver basierend auf person:description() +? room operators + + "local" admin levels in rooms +? disallow binary output for tn-users (use LDMUD internal filters) + damit die keine komischen codes zugesandt kriegen können ++ idle events - _notice_attention ohne beeps falls nicht idle etc ++ /alarm