vim:nosmarttab:syntax=diff
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
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
________________________________________________________________________
== NEXT RELEASE ========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
? support tls multiplexing on all suitable ports
? bugs in psyced install procedure
- pointless to keep gentoo files in this git, if they can't be updated
separately
________________________________________________________________________
== currently being inspected ===========================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- jabber logout isn't announced or offline avail isn't processed
... apparently other side did not logout properly, as it doesn't happen always
- neither USE_THE_NICK or USE_AUTOALIAS work flawlessly. in the case of
the latter, _nick either displays without uniform for remote people,
or it occasionally shows a room's nick instead of the user's nick.
they way to solve this is to get rid of _nick in the protocol, it seems.
therefore we need to upgrade all servers to properly be able to display
_source, _target and _context in psyctext before we can start migrating
templates and removing _nick vars. during this tradition we keep the
USE_THE_NICK code running. several "invite issues" should be solved once
nicks are gone.
- psyced.org tells me: Ungültige Route nach psyc://psyced.org
im psyc://psyced.org/~lynx Context festgestellt.
? who's gonna clean up the mess of having too many websites ?
________________________________________________________________________
== psyced 1.0 ==========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
SPYC (implementation of http://about.psyc.eu/Specification)
* to activate spyc support, defined USE_SPYC
it will attempt to use new syntax on outgoing links by default
* to debug verification, define USE_VERIFICATION
* to spend an extra round trip time negotiating, define USE_FEATURES
- net/spyc is buggy and incomplete
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.
hmm.. not sure about this idea, but we can move forward anyway:
+ REMOVE ALL _nick VARS and extract nick from uniforms
or rather, let raliases resolve all uniforms to nicknames (uni2nick)
? support addressing of uniform portions by psyctext entity syntax
? shouldn't it be display-side job to decide how a [_source] is to be shown -
nick/alias when a friend (or local?), full uniform when unknown...
so all [_nick] should simply be replaced by [_source] etc.
! implementing the latter approach with the uni2nick callback strategy!
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
? can we even afford to have a setting to *disable* this behaviour?
+ 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).
! whenever a _context is output, its nick will be auto-added to raliases
problems that should disappear when we move away from _nick's:
- IRC shows "*** k kindly asks for your friendship." for remote
friendship requests. eh! where's the uniform!?
- remote /topic shows wrong nick
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!!
ARCHETYPE PLACES
? 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
- REGISTERED_USERS_ONLY does not behave properly on IRC port
(see also NO_NEWBIES ... clean up and rename?)
? is it a good idea to use SIGS in user:cmd, too? not sure!!
- 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
________________________________________________________________________
== TOP DELEGATES for 1.0 ===============================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- world/static/index.html should be generated to contain applet port
- fix member list in applet
* see also APPLET, ANNOUNCEMENT, JABBER, FILE TRANSFER
+ 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
+ add a _time_sent whenever messages are queued for later delivery, like
when there is no circuit yet.
+ 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)
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
- experimental rename fails sometimes:
Attempt to rename to existing object '~nautilutz'
possible fix: separate user identity from user access interface
+ fippo insists on the uni/client split and saga has been asking for years..
= separate user identity from user access interface
but it is a messy piece of work (i tried to do it and stashed the branch)
+ and it allows for multiple jabber resources, of course
(but it means we need to actively support UNRs for UNLs in entities)
? 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.
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...) ==============
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
? XMPP: connecting to psyced.org with psi pops up a profile window everytime
? XMPP: first reply to a stranger's remote psyc message did not show up in psi
? 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.
... is this still happening with the new fixes?
ASTERISK IN XMPP: UNIFORMS
- 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?
- is psi having a problem with this, too?
- 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
10Just 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!?
? 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?"
? but why? you shouldn't need to run install.sh more than once!
+ 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
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- /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...
- 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
- 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 XX.XX.XX.XX)
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"
- 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.....!
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 ======================================================
- according to rfc and ircd source IRC parser should accept when the last
argument is just a word instead of a phrase prefixed by :
this is unusual, but legal: "PRIVMSG #blah hello"
+ 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.",([
"_INTERNAL_source_IRC": "c|h|a|o|s!c|h|a|o|s@ve.example.com",
"_INTERNAL_nick_me": "example",
"_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