-
Notifications
You must be signed in to change notification settings - Fork 1
/
CHANGESTODO
3934 lines (3610 loc) · 175 KB
/
CHANGESTODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
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
|
| This file is mostly being used by lynX. The public bug tracker for psyced
| resides at https://projects.tgbit.net/projects/psyced/ and contains the
| same stuff in a more multiuser accessible fashion.
________________________________________________________________________
== SERIOUS!!! ==========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- check in user:input() if data is in utf8 (using RE_UTF8) in order to produce
proper error messages before it is processed further and may end up in
net/jabber's emit() where it is dropped silently (see CHARS_XMPP.log)
- make polly use oauth
- remote psycers do not always show up properly via jabber client + MUC
- /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)
- psyced's memory of places joined is weird -- and neither the default
place from psyced.ini, nor the autojoin rooms in the irc client seem
to make a difference
- "invalid context" errors happen where local rooms send _context
as string uniform while local users expect the object pointer. huh?
LPC
- large submissions into scratchpad can crash the driver
- configure script fails on libidn now being in glibc
- buffer stuff in erq
________________________________________________________________________
== NEXT RELEASE ========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
+ active certs: have data/host/psyc.host.name.pem contain tls cert
for this host, so when that file exists psyced automatically tries
a tls_init_connection() when psyc-connecting that host and checks if
the certificate is still correct. it also does on incoming tls.
- net/jabber reissues unnecessary friend() requests whenever a user simply
reorganizes friends into other roster groups
- MASQUERADE nicks show up with recipient's nick sometimes. bad. vars were
"_nick":"shouldbe","_nick_place":"welcome","_nick_local":"reallywas"
it should have shown either shouldbe or reallywas, but it showed my own.
- interserver xmpp /me expects no leading newline, but pidgin recently
started sending one
- autorefetch twitter isnt working
http/fetch is too complicated. throw out the queue and callback logic. kiss!
? 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
+ teach net/smtp to trust localhost etc.
+ teach net/smtp to ask recipient object if spam rules are to be applied
________________________________________________________________________
== currently being inspected ===========================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- https://psyced.org/~lynX should use web browser language, not mine
- install.sh/configure doesn't *ensure* libidn is available
- newbies are allowed to open new owned rooms
fippo sagt: ergo brauchst du nen exit-hook der owner löscht wenn der n00b-owner aus dem raum geht
- 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 ?
- when provided with a _focus pointing to yourself, _request_execute will
still try to forward a command to the "current place" - a uniform or
object is passed to parsecmd(data, dest) but dest is ignored later in cmd()
- _source_relay should point to tg, not foo (only happens with local users)
.
:_source.psyc://x-net.hu/~foo
:_target.psyc://3e44aa49.XXX:-52801/
:_source_relay.psyc://x-net.hu/~foo
:_nick.tg
:_time_INTERNAL.1239787956
:_nick_target.psyc://x-net.hu/~foo
_message_private
halo
.
? should /load inform that errors go to the console?
________________________________________________________________________
== psyced 1.0 ==========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> SPYC
- net/spyc depends on libpsyc being compiled into the driver
if it is available, it will be activated passively
- #define USE_SPYC if you want outgoing connections to require libpsyc
_ to debug verification, define USE_VERIFICATION
_ to spend an extra round trip time negotiating, define USE_FEATURES
> 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
+ allow newbies to use /nick and switch to a different newbie name?
(also, forbid +alias from being used by newbies?)
> 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 <message to='[email protected]/Home' from='[email protected]/irc' type='chat'><body>oops is a roving piker.</body></message>
* 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 <arguments>"
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:[email protected] 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.
- psyced spits out _error_rejected_relay_incoming for hostnames that have
been redirected using SRV. x-net.hu's A record is still being checked.
_psyc._tcp.x-net.hu has SRV record 0 0 14404 psyc.x-net.hu.
+ XEP-0227: Portable Import/Export Format for XMPP-IM Servers
________________________________________________________________________
== 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 <a name> in die zeile
genommen werden und mit </a> 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?
like.. gateway for email alerts from http://www.dernewsticker.de/
and google alerts obviously
- /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
- auch derb, er akzeptiert ".xx" statt "."
- /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?
> TWITTER
+ resolve redirect-urls before forwarding to subscriptions, that means,
calling http/fetch on http://tr.im/whatever urls until it no longer
returns a 30x redirection code. [improves privacy btw, since all those
redirect services log your access for the one who installs them]
________________________________________________________________________
== OTHER MAJOR TODOS ===================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- occasionally double data sets for psyc://ve.symlynx.com/~nick and nick
+ 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:[email protected] moin.
Filter: kuchn_kuchen_dre_am empfängt keine Nachrichten von Fremden.
Du sagst mailto:[email protected]: 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?
> ERROR HANDLING
- 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.
: added PPL_NOTIFY_INACTIVE to peers.h but actually this needs a more
generic solution for all contexts. see krasser rewrite.
? 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
<fippo> sollte nicht sein
<lynX> 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
>>>
- unnecessary refriendship requests
wenn ich mit Alias: xmpp:[email protected] = 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:
<message to='#[email protected]/lynx' type='error' from='[email protected]/Sisko' xml:lang='en'>
<body>
nein, hatten wir noch nicht gemerkt</body>
<error code='404' type='wait'>
<recipient-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Recipient Is Unavailable</text>
</error>
</message>
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:[email protected] 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 <body></body>. 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:[email protected] sagt Dir: test
would be nice to see the nickname at least.. ;)
- (xmpp:[email protected]/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 <enter>
... 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?
<?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' id='1216134774'><stream:error><xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>
- 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...) ==============
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- display twitter notices somehow
- when 'localhost' is chosen as server name, psyced will append invalid
dot and space in jabber output:
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><jid>test@localhost. /(null)</jid></bind>
? 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 '*'
<message to='[email protected]' type='groupchat' from='*[email protected]/lynX'><body>/me asks: you see me?</body></message>
<message to="*[email protected]/lynX" type="error" from="[email protected]">
<body>/me asks: you see me?</body>
<error code="503" type="cancel">
<service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</message>
- 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 <message/>
- authing an unregistered user should not be permitted
? der eigentliche join kommt mit kaputtem tag
<presence to='[email protected]/Home' from='#[email protected]/nosy'
id='[_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 [email protected]/x und es kommt als [email protected] 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<< [email protected]/x
<deb>
<presence id="4">
<priority>10</priority>
</presence>
<message id="5" to="[email protected]/x" type="headline">
<subject>Just a test</subject>
<body>test body</body>
</message>
</deb>
recv>> [email protected]/x
<deb>
<message from="[email protected]" to="[email protected]/x" type="chat">
<body>test body</body>
</message>
</deb>
- 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<< [email protected]/x
<deb>
<presence id="4">
<priority>10</priority>
</presence>
<iq id="5" to="[email protected]/x" type="get">
<query xmlns="http://jabber.org/protocol/disco#info"/>
</iq>
</deb>
elmex: auf den disco bekomme ich 0 antwort
elmex: [email protected]/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<< [email protected]/x
<deb>
<presence id="4">
<priority>10</priority>
</presence>
<iq id="5" to="[email protected]/x" type="get">
<query xmlns="jabber:iq:version"/>
</iq>
<iq id="6" to="[email protected]/x" type="get">
<query xmlns="broken:iq:request"/>
</iq>
</deb>
recv>> [email protected]/x
<deb>
<message from="beta.ve.symlynx.com" to="[email protected]/x" type="error">
<error code="503" type="cancel">
<service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</message>
</deb>
- 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 <body> 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 <presence to='[email protected]/Home' from='[email protected]/irc'><x from='[email protected]/irc' stamp='[_INTERNAL_time_jabber]' xmlns='jabber:x:delay'/></presence>
- <presence to="[email protected]/mozdev" from="[email protected]">
<x xmlns="jabber:x:delay" from="[email protected]"
stamp="[_INTERNAL_time_jabber]"/>
</presence>
- 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