$Id: CHANGESTODO,v 1.1650 2008/12/30 12:35:00 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 =========================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ - remote IRC place does not send names listing on /join - remote IRC /part shows no reaction at first attempt +++ not limited to IRC!! thx marenz - /set multiplace should be ignored for rich accesses - XMPP: first reply to a stranger's remote psyc message did not show up in psi ? would you prefer psyced to store hashed passwords by default ? - IRC shows "*** k kindly asks for your friendship." for remote friendship requests. eh! where's the uniform!? - remote /topic shows wrong nick (abolish _nick and this problem disappears) - /m freenode:symlynx hey Sorry, _message_private is not supported by the IRC gateway. huh? wasn't that once the point to make them? debug... - tjgillies ponders: connecting to psyced.org with psi pops up a profile window everytime - tjgillies: meebo doesn't let you put * in MUC name AFAIK the xmpp: uri does not forbid * from the URI RFC thus meebo should be incorrect here. we'll have to talk to them.. - google talk also makes funny errors, maybe because of the '*' /me asks: you see me? /me asks: you see me? - minor paranoia thing: - cvs-move archetype.pl out of the sandbox - change the require in psyconf to point to the new path ! profiles.pl and its Makefile aren't a real threat, we don't expect anyone to run them, they are for developers only. - 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.....! ? archetype.gen & other places: 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 - 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* ? in gui clients this could be a menu option in a buddy list: "contact a common friend" .. and of course when /surf'ing ? 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' possible fix: separate user identity from user access interface (see below) - REGISTERED_USERS_ONLY does not behave properly on IRC port (see also NO_NEWBIES ... clean up and rename?) - still UTF8 problems, once a day typically: [Thu Jul 31 22:10:57 2008] C:xmpp:somewhere "*regexp: bad UTF-8 data " "/me würde auf '96 tippen ? tg reports inconsistent display of availability states in friend contextes so far unable to reproduce ________________________________________________________________________ == NEXT RELEASE ======================================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ + before doing an announced new release, psyced should accept old psyc syntax but send new psyc syntax by default! ? support tls multiplexing on all suitable ports ________________________________________________________________________ == psyced 1.0 ========================================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ INVITE ISSUES - remote /invite is shown without uniform, just #nick_place remote invite thus doesn't work for ircers.. beta's lynx invites psyc://psyced.org/~gynx into TEST. gynx thinks it has to join #TEST on psyced.org, not on beta. only +follow behaves correctly, but clients don't use that - 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 <> ? invite-only places: does a double /invite uninvite people!? (and is it a feature or a bug?) - ircinvite() crashes when given wrong arguments + _notice_invitation with a _tag could allow other entities than the explicitly invited one to follow suit - /invite's can get lost because they are transmitted by UDP unless there is a circuit already (should it be a _request!?) - /invite should do remote echo like _message_private, not local 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 + support addressing of uniform portions by psyctext entity syntax (how does psyctext state support fit into that picture?) 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 oops is a roving piker. * see also various PRESENCE boxes DECENTRALIZED STATE / PERSISTENT CONTEXT SLAVES - do not send revision with every cast + we could use better integration of availability because right now CACHE_PRESENCE doesn't work + 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 see PROFILES for all the issues that depend on this one being fixed first. - w("_warning_usage_set_language", "Mittels \"/set language de\" kann zur deutschen Sprache gewechselt werden."); cmdvars = ([ "_command_character" : cmdchar ]) ); ? cmdw() - makro für meldungen mit automatischem cmdvars? ... oder lieber eine saubere state implementierung, weswegen der cmdchar im state abgelegt ist, und jedes template darauf zugreifen darf? "Usage: [_target->_character_command]command " kann man ja erstmal im psyctext für _target supporten, remote state (_source, _context) kommt später.. see http://about.psyc.eu/Talk:Entity + 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 GENERIC CONTEXT SUBSCRIBE / 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 + FRIEND_ECHO ... send echo for /fr type commands from recipient not from own UNI (see #ifdef FRIEND_ECHO) ... or just rewrite it all into context subscription!! ________________________________________________________________________ == TOP DELEGATES for 1.0 =============================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ - bartman sagt: psyconf erkennt keine absoluten pfade bei _path_PEM_key und _path_PEM_certificate - 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.. ;)) - "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) - registering target xmpp:lynx@ve.example.com isn't working. psyced reconnects by xmpp, then switches to psyc every time - gino75 schließt mit Dir Freundschaft. why does it show account name instead of alias? (gmail) - 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 - 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 - 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) + change of nick/identity / account deletion & transfer / redirection services ... we have forwarding by /set id now. it's a start. + /set redirect temp|perm in usercmd.i for users - place redirection doesn't work for ircII: client still thinks i am in the first room while i get messages from the second room. when i type stuff to the first room, it doesn't even forward to the second. ________________________________________________________________________ == MINOR DELEGATES ===================================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ - psyced generates tags for /enter operations. since these weren't generated by a client they may confuse a client. fippo thinks these _tag and _tag_reply should be removed from the messages before the get forwarded to clients. - 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) - move templates from source code into default/en/plain.textdb .. maybe write an automation to do it? they're just too many! run more mailcast gateways!! 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 - 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. ? does spyc/* fix this? - parse.i erlaubt es den begrüßungspunkt wegzulassen wenn man stattdessen ne leerzeile liefert. aua -- egal, wir wechseln auf spyc - /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 - tg reports: the nick shows up like net/irc/user/#foo in IRC + 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? ... bzw. git 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 =================================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ + provide a tuning for ACTIVE server-side PING (keepalive) ? see http://about.psyc.eu/Ping for explanations. ? 420 added place profiles for psyczilla! reorganize listDescription() ? - warum wird eine mailto: uniform durch legal_name() gejagt? /m mailto:kuchn@example.dre.am moin. Filter: kuchn_kuchen_dre_am empfängt keine Nachrichten von Fremden. Du sagst mailto:kuchn@example.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 _flag_disable_info_session as other default of /set greeting auto ? apply more TAGGING (tagged callbacks also avoid the monster switches) /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 CIRCUITRY - _request_circuit_shutdown isnt issued or doesnt arrive or is the disconnected-detection buggy? + net/circuit:pushback TODO: // alright. so this is where we want to do something // differently, like remember that this host didn't work. ? another interesting aspect about circuits.. if you retry a lot, then you don't give dyndns a chance to get updates through. psyced gets stuck trying an old ip until retries are over. but shouldn't dyndns work anyway? why is this happening? (happened for tjgillies on EC2) - 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 ? two approaches to address the issue: ? move parts of the ppl data structure into context masters, then have a flag remember when a member induced a failure and keep him quarantined until he is seen as being alive again ? simpler: keep the distribution tree intact, but the last host with the repeatedly failing outgoing connection provides occasional failure reports to all involved senders, then silently drops things that were undeliverable (in the case of packet ids, the broken recipient still has the possibility to recover the next day) - Repeatedly unable to reach whatever.example.com in order to deliver a _message_private to 0. Why does it say "0" here.. ouch. ? what to do when hosts talk faster then we resolve them? see around _error_invalid_host_slow 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 FOLLOW INVITES + /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! - 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: oops schließt mit Dir Freundschaft. TAV möchte mit Dir Freundschaft schließen. bin mir ziemlich sicher, dass es keinen lokalen oops gibt.. es handelt sich um eine fehlerhafte doppelte darstellung vom TAV alias ohne sein @gmail.com!? einige stunden später: Du bist mit oops 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@example.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 PROGRAMMABLE USER IDENTIFICATIONS & MULTIPLE CLIENT INTERFACES + fippo insists on the uni/client split.. = separate user identity from user access interface (and saga has been asking for years) .. read also 'person.gen' below - this would probably also solve the issue with the ~nick object name plan + and it allows for multiple jabber resources, of course ? one day we could 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... ;) ? consider also what CONTEXT CHANNEL requirements the new identity has 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 - CONSOLE_CHARSET remains an issue, because some debug outputs or runtime errors will want to %O arbitrary data which will not be utf-8 compliant, so it is still necessary that CONSOLE_CHARSET learns to be easy about it == 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! - when a _target does not comply to the rules, a message needs to be replied to with an error. currently however, handling falls thru to rootMsg() like this: Circuit got _request_link to psyc://psyced.org/~White Spaced Username from psyc://10.20.30.40:-54925/ Circuit got _request_input to psyc://psyced.org/~White Spaced Username from psyc://10.20.30.40:-54925/: Hi Circuit got _request_execute to psyc://psyced.org/~White Spaced Username from psyc://10.20.30.40:-54925/: QUIT == PSYC 1.0 beta ======================================================= - should ignored people receive an echo for the sake of not being distinguishable from not ignored people? yes... but is a nasty change to do 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: 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 =================================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ - /x ALIAS aka xmpp:example@gmail.com results in "[_nick_target]" ist nicht erreichbar. example ist online + man hat friend status. - "/i user@host" doesn't work for PSYC hosts. it gets rendered by net/jabber into jabber-only code, but is later sent over psyc. to fix this we need to do the queuing before the jabber code gets its hands on it? ? http://www.xmpp.org/rfcs/rfc3921.html#substates ? _nick_local and coolname are shown, but cannot be identified localMUC: - MUC member list may be incorrect after psyced server restart.. we should probably castmsg all local leaves at shutdown - 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 - 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) + 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. - joining a psyc channel from XMPP-S2S with different handle (nick) is still causing problems ? M1: apparently something in psyced's MUC implementation is making mcabber crash :( remoteMUC: - whispering in remote MUCs: xmpp:psyc@conference.jabber.org sagt Dir: test would be nice to see the nickname at least.. ;) - (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 - fake any sort of showMembers() for remote MUCs...? or actually implement it? looks so stupid on telnet when typing ... then again, telnet is the only protocol that could use that.. scrapped - "asks" kommt blöd.. entweder visiblespeakaction immer, oder gar nicht (implement visiblespeakaction in net/jabber) - ausserdem wird kein asks erzeugt wenn jabberisten fragen stellen - wenn man 5269 antelnettet und garbage reinkippt.. dann sagt psyced nix und timeoutet sollte er nicht sowas hier senden? - xmlquote vars at psyctext rendering time instead of guessing which vars to quote in mixin_render:msg() - properly inspect muc error codes instead of generating _failure_place_enter_XMPP "jabberish reasons" ________________________________________________________________________ == JABBER CLIENT ISSUES (...experimental is justified...) ============== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ - accurate availability values from friends aren't stored and delivered - re-subscribe isn't properly handled (so we do friend(0) earlier instead) - when unsubscribing a user, no proper ack is sent to client (but relogin helps ;)) - v("place") isn't automatically set when actively joining a chat - the /me command ist not properly treated - incoming friend requests from lastlog (in absence) are not delivered! - incoming xmpp:u@h and outgoing u@h profile data isn't properly merged also 'user without @host' seems to produce funny fx - moving people around in roster groups is not stored - xx cannot handle friendships yet shouldn't be a - authing an unregistered user should not be permitted ? der eigentliche join kommt mit kaputtem tag - 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: 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@example.org/x und es kommt als testxmpp2@example.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@example.org/x 10 Just a test test body recv>> 2nd_testxmpp2@example.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.example.com/x 10 elmex: auf den disco bekomme ich 0 antwort elmex: testxmpp@beta.ve.example.com/x bekommt den nichtmal fiPP: wir mögen resourcen überhaupt nicht fiPP: das wird alles gefiltert und vom server beantwortet - elmex: disco geht auch nicht fiPP: dass wir auf iq teilweise mit message antworten ist nen uralter bug send<< 2nd_testxmpp@beta.ve.example.com/x 10 recv>> 2nd_testxmpp@beta.ve.example.com/x - autojoin() is disabled, so jabber clients never get to enter newsfeed places. no news is bad news sometimes. maybe we should simply suppress all output of autojoins by maintaining an extra jabber-only list of "actively entered" muc places, then have all other contexts output as server messages (newsfeeds, rarely used chatrooms). the user can then decide to enter the context "actively" whenever he intends to speak on it, or simply wants a seperate tab or window for it. this is treating jabber clients a bit like gui tools or webchats.. but.. so what. [ other approaches could include some abuse or multiplexing of pubsub with muc protocols to handle all aspects of psyc contexts, but that would still need such a jabber-only context list, so it's a superset or later feature of this. if i'm not confused pubsub protocol would merely serve to integrate the /subscribe command better into the jabber ui experience, and provide a correcter display vehicle for messages than server notices.. right? --lynX ] _request_list_item in person.c is a placebo. it would tell clients which places are known and possibly have them autojoin. this may not follow the psyc model much, but it's better than nothing at all. maybe there's also some protocol for clients to store which places are to be autojoined - which would be the complicated way to do subscriptions. still autojoin doesn't act the right way in all situations, so it's not enough. hey wait.. there is jabber:iq:private code in jabber/user.c that should do just that - it even provides autojoin='1' but i haven't seen a single client honor that. maybe just some bugfixing necessary? - 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 - 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 ? ouch.. wir haben immernoch psyctext fehler: net/jabber/user#example - - 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 =================================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ - _charset_console can still lead to unexpected convert_charset errors when outputting random data. convert_charset must be non-fatal here! ? 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 ========================================================= ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ - 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 ? marenz suggests /sub could first ensure the target actually likes to be subbed, that requires a tag-triggered action on reception of successful entry.. and by consequence, should we also support current behaviour in the form of /sub -f (aka force) ? flags in chat commands? yeah why not.. it's a nerd thing anyway these days. that means we need a getopt efun/implementation for LPC.. lol ? hmm.. htuniform() in http/library isnt being used by anything why did i code it then? there must be a reason ? /x currently tells anyone about crypto level quality of a person should this be more private? + METHOD FILTERING -> CHANNELS fippo hotzenplotzt: hrmpf hrmpf. ich will webexamine setbar aushaben bitte! lynx: programmier den ultimativen filter befehl lynx: .. /filter ? /set filter presence xmpp:xxx@yyy als user-befehl 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 ? problem: how to allow remote XMPP MUC users to filter web inspection notices? PROFILES ! depend on DECENTRALIZED STATE to get to the next stadium of coolness - exposed lists aren't properly sorted by expose level. a maximum expose should automatically put a friend or group at the top of the profile list etc. ? 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 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 ~> XXX xmpp:base@conference.jabber.org ~> XXX xmpp:base@conference.jabber.org ~> XXX Privatgespräch beendet. PSYC @> Du sagst xmpp:base@conference.jabber.org: XXX Du sagst xmpp:base@conference.jabber.org: XXX Du sagst xmpp:base@conference.jabber.org: XXX "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 ? 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/~oops [psyc://goodadvice.pages.de/~oops@goodadvice.example.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 CLIENTS ======================================================== - tg runs into trouble using _do_enter and _do_leave. apparently the enter-echo is not accepted by the UNI and thus does not make it into _list_places - _do_leave does not forward the echo from remote places back to the client - NEW_UNLINK: place and v("place") aren't in sync (new changes for psyc clients) + 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 RELAYING + net/spyc needs relaying (without parsing even), see TODO in parse_content() ? relaying doesn't work for psyc clients (xmpp: in particular) works for localhost clients works for clients issueing _request_circuit_trust - "trustworthy" needs to be raised for data coming from a client and does _source need to be set to the UNI of the client instead of the server root? probably. + proxy/relaying in wikinotify etc einbauen? == 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 ==================================================== ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ? 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 + http://www.oftc.net/oftc/NickServ/CertFP generic client cert support for all net/* protocols? ? 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) - 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 == 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 ====================================================== + some irc clients do not implement their own pinging, and some NATs really kill your irc session if it is too quiet too long. we need optional server side pings - (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.example.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