jdev - 2022-12-17

  1. Beherit has left

  2. qwestion has left

  3. qwestion has joined

  4. antranigv has joined

  5. adx has left

  6. Maranda has left

  7. moparisthebest has left

  8. moparisthebest has joined

  9. mh has left

  10. mh has joined

  11. qwestion has left

  12. kapad has left

  13. mh has left

  14. mh has joined

  15. antranigv has left

  16. Vaulor has left

  17. Vaulor has joined

  18. kapad has joined

  19. Mx2 has left

  20. thomaslewis has joined

  21. thomaslewis has left

  22. Mx2 has joined

  23. kurtain has left

  24. Vaulor has left

  25. kurtain has joined

  26. thomaslewis has joined

  27. thomaslewis has left

  28. Mx2 has left

  29. thomaslewis has joined

  30. thomaslewis has left

  31. zawarudo has left

  32. xnamed has left

  33. xnamed has joined

  34. Mx2 has joined

  35. thomaslewis has joined

  36. Kev has left

  37. Kev has joined

  38. thomaslewis has left

  39. kurtain has left

  40. kurtain has joined

  41. thomaslewis has joined

  42. Mx2 has left

  43. qwestion has joined

  44. qwestion has left

  45. qwestion has joined

  46. qwestion has left

  47. thomaslewis has left

  48. thomaslewis has joined

  49. kapad has left

  50. thomaslewis has left

  51. wurstsalat has left

  52. thomaslewis has joined

  53. stefan has joined

  54. thomaslewis has left

  55. thomaslewis has joined

  56. mirux has joined

  57. thomaslewis has left

  58. Menel has joined

  59. Vaulor has joined

  60. thomaslewis has joined

  61. thomaslewis has left

  62. thomaslewis has joined

  63. mrDoctorWho has left

  64. mrDoctorWho has joined

  65. MSavoritias (fae,ve) has joined

  66. thomaslewis has left

  67. marc0s has left

  68. marc0s has joined

  69. thomaslewis has joined

  70. Vaulor has left

  71. thomaslewis has left

  72. nicoco_ has joined

  73. nicoco_ has left

  74. Vaulor has joined

  75. inky has left

  76. Alex has joined

  77. Mario Sabatino has joined

  78. Vaulor has left

  79. Vaulor has joined

  80. nicoco_ has joined

  81. thomaslewis has joined

  82. thomaslewis has left

  83. antranigv has joined

  84. Mx2 has joined

  85. nicoco_ has left

  86. nicoco_ has joined

  87. nicoco_ has left

  88. nicoco_ has joined

  89. nicoco_ has left

  90. nicoco_ has joined

  91. nicoco_ has left

  92. mrDoctorWho has left

  93. Beherit has joined

  94. mrDoctorWho has joined

  95. Vaulor has left

  96. thomaslewis has joined

  97. thomaslewis has left

  98. goffi has joined

  99. Vaulor has joined

  100. mrDoctorWho has left

  101. goffi has left

  102. goffi has joined

  103. Laura has joined

  104. adx has joined

  105. nicoco_ has joined

  106. thomaslewis has joined

  107. thomaslewis has left

  108. xecks has joined

  109. nicoco_ has left

  110. thomaslewis has joined

  111. thomaslewis has left

  112. mrDoctorWho has joined

  113. atomicwatch has left

  114. larma has joined

  115. mh has left

  116. debacle has joined

  117. mh has joined

  118. Millesimus has left

  119. atomicwatch has joined

  120. Millesimus has joined

  121. wurstsalat has joined

  122. atomicwatch has left

  123. atomicwatch has joined

  124. dezant has joined

  125. Menel has left

  126. Menel has joined

  127. Vaulor has left

  128. inky has joined

  129. Vaulor has joined

  130. PapaTutuWawa has joined

  131. dezant has left

  132. dezant has joined

  133. dezant has left

  134. dezant has joined

  135. Maranda has joined

  136. Vaulor has left

  137. nik has joined

  138. Mjolnir Archon has joined

  139. atomicwatch has left

  140. atomicwatch has joined

  141. nik has left

  142. Vaulor has joined

  143. Matrix Traveler (bot) has left

  144. homebeach has left

  145. homebeach has joined

  146. Matrix Traveler (bot) has joined

  147. xecks has left

  148. xecks has joined

  149. Millesimus has left

  150. inky has left

  151. Millesimus has joined

  152. inky has joined

  153. rubi has left

  154. techmetx11 has left

  155. techmetx11 has joined

  156. nik has joined

  157. rubi has joined

  158. Vaulor has left

  159. MSavoritias (fae,ve) has left

  160. nik has left

  161. atomicwatch has left

  162. Laura has left

  163. Vaulor has joined

  164. rubi has left

  165. atomicwatch has joined

  166. rubi has joined

  167. dezant has left

  168. xnamed has left

  169. Laura has joined

  170. dezant has joined

  171. zawarudo has joined

  172. xnamed has joined

  173. MSavoritias (fae,ve) has joined

  174. zawarudo has left

  175. zawarudo has joined

  176. Menel has left

  177. debacle has left

  178. Sam has left

  179. Sam has joined

  180. antranigv has left

  181. mrDoctorWho has left

  182. mh has left

  183. mh has joined

  184. debacle has joined

  185. Menel has joined

  186. debacle has left

  187. debacle has joined

  188. Patiga has joined

  189. Martin has left

  190. Martin has joined

  191. Martin has left

  192. Menel has left

  193. Menel has joined

  194. Martin has joined

  195. Laura has left

  196. debacle has left

  197. Menel has left

  198. Menel has joined

  199. mrDoctorWho has joined

  200. MSavoritias (fae,ve) has left

  201. MSavoritias (fae,ve) has joined

  202. pep.

    Old question: is there any concrete reason why a MUC component shouldn't host a room on a bare domain jid? Apart from historical reasons / "it's more or less like this in the spec" etc.? Maybe there are resources on this? it's definitely not the first time this is asked

  203. nik has joined

  204. Menel has left

  205. Menel has joined

  206. sonny has left

  207. sonny has joined

  208. rom1dep has left

  209. nik has left

  210. pep.

    https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat maybe this should be in here somewhere.

  211. debacle has joined

  212. pep.

    Also are new-ish MUC extensions/improvements referenced somewhere?

  213. nik has joined

  214. rom1dep has joined

  215. oshn has left

  216. zawarudo has left

  217. zawarudo has joined

  218. nicoco_ has joined

  219. lovetox

    whats a bare domain jid

  220. lovetox


  221. pep.


  222. lovetox

    so the whole component can only host a single room?

  223. pep.

    no, it would still be possible to create room@muc.service

  224. lovetox

    ? why are you not continuing my example

  225. lovetox

    and use something totally different now

  226. pep.

    Is it really important?

  227. lovetox

    you mean room@mucservice.com?

  228. pep.


  229. nik has left

  230. lovetox

    so a disco on mucservice.com returns all kind of things

  231. Zash

    not xmpp:muc.example?join ?

  232. lovetox

    its a muc component, but also a room

  233. lovetox

    but also hosts accounts

  234. pep.

    lovetox, why accounts

  235. pep.

    Basically I'm asking if the concept of "MUC component" is necessary

  236. lovetox

    How do you create a room if you dont know the jid of the muc component?

  237. zawarudo has left

  238. pep.

    Well you know because you are given the adresse of one, either disco#items from the server, or some other user

  239. lovetox

    no disco items would not return anything anymore

  240. pep.

    Why not

  241. lovetox

    you just said "do we need the concept of a muc component"

  242. lovetox

    so you are questioning if this should exist

  243. lovetox

    if something does not exist anymore it cant be in disco info

  244. nicoco_ has left

  245. zawarudo has joined

  246. pep.

    Well clients still need something they know they can create rooms out of, so yeah I'm still doing to give them a JID to do so

  247. pep.

    Well clients still need something they know they can create rooms out of, so yeah I'm still doing to give them a JID to do so from

  248. lovetox

    sie and that jid is called "component"

  249. lovetox

    so yes we need that

  250. pep.

    But that's the only thing one needs right?

  251. Matrix Traveler (bot) has left

  252. homebeach has left

  253. homebeach has joined

  254. pep.

    If this jid is actually a room doesn't matter, does it

  255. Matrix Traveler (bot) has joined

  256. pep.

    Because the client is likely to try to create foo@muc.service instead of just joining muc.service

  257. Zash

    pep., so are you talking about having rooms without nodepart or not?

  258. lovetox

    depends, last time we discussed this there is no way to differentiate between a room and a muc component

  259. pep.

    Zash, yeah

  260. Zash

    I find it very unclear what this is about

  261. pep.

    I'm wondering if I should make a different in my component project at all between the jid without nodepart and others.. It does look like a pointless distinction from the component PoV

  262. nik has joined

  263. rom1dep has left

  264. Zash

    There ought to be a disco#info thing that means "I am a room" and a different disco#info thing that means "I allow creating rooms"

  265. pep.

    lovetox, ok then I guess that's settles it?

  266. pep.

    Zash, hmm

  267. lovetox

    as i said there is no way to detect a component

  268. lovetox

    no client would join mucservice.com

  269. lovetox

    because you returned it in disco items as a component

  270. lovetox

    i cant join a component

  271. lovetox

    its not a room

  272. pep.

    lovetox, well that's just because they haven't been implemented to do so, doesn't mean it's not possible

  273. pep.

    (And actually poezio does)

  274. lovetox

    yeah you can do anything, the question is, is there a reason beyond "hey im a special snowflake and i want to create rooms that half of the clients cant join"

  275. lovetox

    there is nothing wrong with room@group.service.com

  276. lovetox

    its clear for everyone, it separates concerns

  277. Zash

    what if you wanted to build a thing where you have user@host and #group@host ?

  278. Zash

    (like, say, irc transports)

  279. pep.

    Zash, please don't do that (differenciating by JID :p)

  280. Zash

    Biboumi already does, no?

  281. pep.


  282. pep.

    Well, yes..

  283. pep.


  284. pep.


  285. pep.

    But it's mapping IRc..

  286. pep.

    But it's mapping IRC..

  287. Link Mauve

    “15:41:14 lovetox> ? why are you not continuing my example”, perhaps because this is a porn website. :D

  288. Zash

    Doesn't have to encode into JID, could have the server keep track of whether a thing is a user or room. Maybe even both? But best not.

  289. Zash

    "I only have this dyndns hostname and can't have subdomains" is something that comes up every now and then

  290. nicoco_ has joined

  291. pep.

    So.. in summary, a client still needs a place that tells it "You can create rooms here"?

  292. pep.

    And that's about it?

  293. pep.

    It can also be a room though

  294. pep.

    It would have both roles

  295. Zash

    Maybe we get rid of that entirely and move to an iq stanza directed at something advertising the corresponding feature, with the room JID returned in the result

  296. lovetox

    yes, if your question is technical nature, yes its possible

  297. pep.

    Zash, I thought about that also yeah

  298. Zash

    Then we can get rid of the weirdo locking flow

  299. Zash

    (but we keep the regular flow ;))

  300. pep.

    (Yeah we like flow)

  301. Laura has joined

  302. nik has left

  303. pep.

    0045 doesn't have this thing that says "you can create rooms here" right? It's generally assumed that one can do so on a bare domain JID

  304. pep.


  305. Zash

    http://jabber.org/protocol/muc + conference/text or somesuch?

  306. pep.

    Well yeah but a room would also have that right?

  307. Zash

    eh, rooms have that too

  308. MSavoritias (fae,ve) has left

  309. rom1dep has joined

  310. nicoco_ has left

  311. zawarudo has left

  312. nik has joined

  313. zawarudo has joined

  314. nik has left

  315. pep.

    Ah and /list is also done on the component generally

  316. pep.

    Does disco#items on a room do anything?

  317. pep.

    It doesn't look like it

  318. rom1dep has left

  319. nik has joined

  320. zawarudo has left

  321. raghavgururajan has joined

  322. zawarudo has joined

  323. oshn has joined

  324. inky has left

  325. zawarudo has left

  326. nik has left

  327. nicoco_ has joined

  328. pep.

    lovetox, Zash, https://wiki.xmpp.org/web/index.php?title=XEP-Remarks%2FXEP-0045%3A_Multi-User_Chat&type=revision&diff=14249&oldid=13072 does this look correct? Any comment?

  329. zawarudo has joined

  330. atomicwatch has left

  331. debacle has left

  332. nik has joined

  333. zawarudo has left

  334. zawarudo has joined

  335. sonny has left

  336. sonny has joined

  337. thomaslewis has joined

  338. atomicwatch has joined

  339. inky has joined

  340. MSavoritias (fae,ve) has joined

  341. MattJ

    pep. [15:28]: > Does disco#items on a room do anything? It is supposed to list occupants, but most servers/rooms disabled it for privacy

  342. pep.


  343. pep.

    So this one feature would conflict?

  344. thomaslewis has left

  345. nik has left

  346. nik has joined

  347. rom1dep has joined

  348. Zash

    Why would it?

  349. Zash

    Or, why would it not conflict as much as XMPP does with itself already?

  350. Zash

    You pretty much have to disco#info each item anyway to find out what it is

  351. Zash

    It could be commands, it could be rooms, it could be pubsub nodes, who knows‽

  352. lovetox

    but disco items on the component, lists rooms usually

  353. pep.

    What lovetox says. If a JID is both a room and a component, that is.. it's a room and it allows room creation

  354. lovetox

    pep., in general we should avoid any situation where a thing is 2 things at once in my opinion

  355. lovetox

    it only leads to trouble

  356. pep.

    lovetox, I agree. And it's sad that this one thing conflicts :/

  357. lovetox

    xmpp has often the problem that without disco info you cant know what a thing is, adding now on top that even if you disco, it is multiple things at once is a new kind of bad

  358. pep.

    Are there any others things that would conflict?

  359. nik has left

  360. lovetox

    basically everything that you direct at the jid, needs then special handling by the server

  361. lovetox

    you would need fuse responses with results from both entities

  362. zawarudo has left

  363. lovetox

    like adhoc commands for example, probably one of the easier things

  364. lovetox

    i cant imagine that any server can support this by default or?

  365. pep.

    can support what?

  366. lovetox

    room and component as the same jid

  367. pep.

    Prosody supports room creation on the bare domain jid

  368. zawarudo has joined

  369. lovetox

    i didnt say nobody supports it

  370. lovetox

    i said its not supported by default, you probably need to add special handling at many places to make it possible

  371. pep.

    In prosody, I don't think so no

  372. nicoco_

    Speaking of a thing being two things at once, now that I do MUCs in slidge, gajim lists them under ‘rooms’ and not ‘gateways’ anymore. Is it just a UI thing, or is there anything wrong with a component having both a gateway and a muc service identity?

  373. lovetox

    how would you know? did you design the prosody architecture :D

  374. pep.

    lovetox, I haven't enabled anything in particular to be able to create the room.

  375. mh has left

  376. pep.

    nicoco_, probably one of the identities is used and not the other. Maybe the MUC identity is served first

  377. pep.

    A client would have to be able to deal with this combination of identities

  378. mh has joined

  379. nicoco_

    Biboumi is also in Rooms - which makes more sense because it’s mostly rooms and also it does not require any ‘subscription to the component’ AFAIK

  380. pep.

    Wait so it's possible to get a list of occupants with disco#items? Without running the 4 iqs? :P

  381. pep.

    Ah, presence not affiliations

  382. nicoco_

    Anyway it does not alter the functionality at, probably separating ‘MUC services’ from ‘gateways’ is ambiguous in the first place.

  383. pep.

    I guess I'm personally willing to dismiss this one feature (getting an occupant list via disco#items, especially if most servers don't do it) as it's possible to get this list by joining.

  384. pep.

    And I'd rather have people join to get this kind of information

  385. nicoco_ has left

  386. nicoco_ has joined

  387. nicoco_ has left

  388. nicoco_ has joined

  389. thomaslewis has joined

  390. Matrix Traveler (bot) has left

  391. homebeach has left

  392. homebeach has joined

  393. Matrix Traveler (bot) has joined

  394. thomaslewis has left

  395. rom1dep has left

  396. zawarudo has left

  397. zawarudo has joined

  398. raghavgururajan has left

  399. nicoco_ has left

  400. sonny has left

  401. sonny has joined

  402. nicoco_ has joined

  403. thomaslewis has joined

  404. nicoco_ has left

  405. nicoco_ has joined

  406. mrDoctorWho has left

  407. mh has left

  408. nicoco_ has left

  409. rom1dep has joined

  410. atomicwatch has left

  411. raghavgururajan has joined

  412. atomicwatch has joined

  413. mh has joined

  414. rom1dep has left

  415. nicoco_ has joined

  416. thomaslewis has left

  417. nicoco_ has left

  418. nicoco_ has joined

  419. nicoco_ has left

  420. thomaslewis has joined

  421. paul has left

  422. larma has left

  423. nicoco_ has joined

  424. xnamed has left

  425. nicoco_ has left

  426. nicoco_ has joined

  427. kurtain has left

  428. nicoco_ has left

  429. xnamed has joined

  430. antranigv has joined

  431. pep.

    https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Why_do_I_need_to_host_my_MUC_component_on_subdomain.example.org%3F ok then, I updated it. It's weird mix of two different but related things I feel, but I think most info is there.

  432. zawarudo has left

  433. thomaslewis has left

  434. thomaslewis has joined

  435. larma has joined

  436. zawarudo has joined

  437. thomaslewis has left

  438. thomaslewis has joined

  439. Mx2 has left

  440. thomaslewis has left

  441. TheCoffeMaker has left

  442. larma has left

  443. zawarudo has left

  444. atomicwatch has left

  445. atomicwatch has joined

  446. atomicwatch has left

  447. _root has left

  448. _root has joined

  449. flow

    personally I believe that MUC JIDs should always consists of a localpart and a domainpart and no resourcepart. and that a MUC service domainpart should not also be a domainpart that hosts ordinary users

  450. flow

    the motivation for the first constrain is that it makes it easy for clients to validate that the entered string is in fact probably a valid MUC address, leading to better UX

  451. flow

    and I had a technical reason, not just a philosopical one like "separation of concerns" for the second constraint. Yes I know that it is technical possible to do that, but it IIRC caused me some other technical trouble

  452. flow

    if you don't write everything down, then you are doomed to forget it…

  453. mrDoctorWho has joined

  454. zawarudo has joined

  455. lovetox

    im not sure the wiki should list whats technical possible, and rather list good practice

  456. mh has left

  457. lovetox

    Its good UX that users can see with one look, if a adress is a groupchat or not

  458. larma has joined

  459. larma has left

  460. mh has joined

  461. lovetox

    i dont see why anyone would actively take steps to prevent that

  462. jubalh has left

  463. jubalh has joined

  464. pep.

    "Its good UX that users can see with one look, if a adress is a groupchat or not" you can't do that "in one look". You need to disco it anyway, it could be a user account otherwise

  465. pep.

    And I would very much like not to restrict what a jid should look like either. I'd rather have clients disco

  466. lovetox

    of course you can

  467. lovetox


  468. pep.

    That could be a user

  469. lovetox

    see, one look you did it :)

  470. pep.

    And that could be a room

  471. lovetox

    pep., you gould be a GPT3 chatbot

  472. lovetox

    im still talking to you though

  473. pep.

    Be serious one second

  474. lovetox

    think about what argument you want to make

  475. pep.

    What are you trying to make me say

  476. lovetox

    mine is, everyone should choose descriptive subdomains so users can easily discover what things are

  477. pep.

    Yeah I disagree that things should be separated as "subdomains", I disagree that this should even be exposed to users anyway

  478. zawarudo has left

  479. pep.

    Some know, (you, me), and that's fine

  480. pep.

    I think sticking to subdomains is slightly shortsighted

  481. zawarudo has joined

  482. lovetox

    how so?

  483. lovetox

    how was it shortsighted of the gajim server, to choose conference as its subdomains for MUCs for the last decade?

  484. pep.

    Joinjabber doesn't have a user host, and will certainly never have one, it's standalone

  485. Link Mauve

    lovetox, to most users, this is an email address.

  486. Link Mauve

    A weird one, since it doesn’t end with @gmail.com though.

  487. lovetox

    it is not, because if you go out of context, you need to attach schemes

  488. lovetox

    and because of great forsight, someone added xmpp:

  489. Link Mauve

    To most users, mailto: is a weird prefix they don’t understand at all.

  490. pep.

    Well then if you trust the source you got the address from, xmpp:?join tells you it's a room. What more do you need

  491. Link Mauve

    Don’t assume just because a JID has conference. in its domain, that users will understand it’s a MUC.

  492. pep.

    And you're proably going to disco it anyway because you need to

  493. pep.

    (for other reasons)

  494. Link Mauve

    pep., ?join is a good indicator, but not every URL producer manages to add it correctly.

  495. lovetox

    it does not matter if a client disco or not

  496. pep.

    Link Mauve, sure. I'm arguing for discoing really :)

  497. lovetox

    this is not about clients

  498. Link Mauve

    disco#info on the user-provided JID is the best you can do really.

  499. atomicwatch has joined

  500. atomicwatch has left

  501. lovetox

    its about how you choose your domain

  502. lovetox

    and maybe we should not chose gajim.org

  503. pep.

    Who cares about the domains. Why would it matter to users

  504. lovetox

    because maybe behind gajim.org is in fact something different

  505. pep.

    (it's fun because I could see you make the exact same argument saying domains don't matter)

  506. lovetox

    yeah why not use IPs

  507. Link Mauve

    Ok, I’m out of this discussion.

  508. pep.

    No I meant, "since domains don't matter, why not to restrict them anyway". Is what I had in mind for you

  509. pep.

    But yeah I guess I'm also out

  510. lovetox

    ok haha im looking forward to your next domain

  511. pep.

    Really is it just UX that you're trying to improve with this?

  512. pep.

    If so I honestly don't understand

  513. lovetox

    with what? choosing a fitting domain name

  514. lovetox

    sorry are you for real?

  515. pep.


  516. lovetox

    are you arguing people should not choose fitting domain names anymore

  517. lovetox

    because we cant trust that befor we click on it, it really is what it says it is

  518. pep.

    We're not talking about the same thing are we

  519. xnamed has left

  520. lovetox

    yes, we are, half of the day you try asking why and how its technical possible to NOT name your component domain after what it is

  521. lovetox

    a muc service

  522. lovetox

    and then you tried to argue, we cant trust the name, so why name it

  523. lovetox

    as i was asking, im not sure where you want to go with that

  524. lovetox

    every sane person will name its muc service, group.domain.org

  525. xnamed has joined

  526. lovetox


  527. pep.

    Every sane person will know you disco a JID

  528. lovetox

    and it not a argument, that there exists a person out there, that doesnt know what a conference is

  529. lovetox

    pep., we are talking about UX for users

  530. lovetox

    not about clients and what they do

  531. lovetox

    a client is a computer program

  532. lovetox

    a domain name means NOTHING to a computer programm

  533. lovetox

    its a series of bytes

  534. pep.

    You're trying to much. I doubt your users ever care about this

  535. pep.

    I certainly wouldn't

  536. pep.

    I mean, I like it when it looks pretty

  537. pep.

    It doesn't have to look like a MUC jid because there is no such thing as a MUC jid

  538. lovetox

    i guess goole should not have used groups.google.com

  539. lovetox

    im sure people hate it that groups.google.com leads to google groups

  540. pep.

    Right, too bad it's a mailing list and not a MUC component

  541. pep.

    (Snikket named their MUC component groups.)

  542. atomicwatch has joined

  543. lovetox

    oh no !

  544. lovetox

    its simple, if i have the chance to give something a name, i will, and thats the whole story

  545. lovetox

    you seem to have the opinion, no i want to hide that it even exists

  546. pep.

    Whether I want to or not, to know if a thing is a thing I need to disco it anyway

  547. pep.

    So there's that

  548. lovetox

    no pep. users dont disco anything

  549. jubalh has left

  550. pep.

    Users don't need to know what it is, they give it to their client

  551. pep.

    They can't use it without a client anyway

  552. lovetox

    ok, so i guess have fun with having your 10 components on the same domain

  553. pep.

    Did you not me see trying to list conflicting features earlier.

  554. lovetox

    tell me how it goes

  555. atomicwatch has left

  556. pep.

    To try and avoid it

  557. lovetox

    ok, so you can give something a name, but rather then just giving it the name what it is, you say, wait i dont want to name it, i rather think a few hours how not nameing it can lead to problems

  558. pep.

    I say there's no need to restrict it arbitrarily if identities don't conflict, yeah

  559. thomaslewis has joined

  560. lovetox

    nobody restricts anything, everyone is just pratical, we can give it a name, it has only benefits if something is named after what it is, just name it and everything is good

  561. atomicwatch has joined

  562. atomicwatch has left

  563. pep.

    Of course it's an arbitrary restriction. Why a sudomain, why not two. Why not only "muc." why not the "muc" tld

  564. lovetox

    i think we established that there is no restriction

  565. pep.

    No, you did on your own

  566. jubalh has joined

  567. lovetox

    nobody restricts you to jump of a bridge, but i guess you will not do it because its not very practial for your future plans

  568. lovetox

    this discussion feels like it

  569. pep.


  570. pep.

    Seriously I should have stopped this chat 1h ago

  571. pep.

    It feels pointless

  572. lovetox

    ok then lets stop, i will watch TV now :)

  573. lovetox

    have a good night

  574. jubalh has left

  575. thomaslewis has left

  576. thomaslewis has joined

  577. atomicwatch has joined

  578. zawarudo has left

  579. inky has left

  580. zawarudo has joined

  581. thomaslewis has left

  582. thomaslewis has joined

  583. jubalh has joined

  584. thomaslewis has left

  585. thomaslewis has joined

  586. thomaslewis has left

  587. thomaslewis has joined

  588. thomaslewis has left

  589. Beherit has left

  590. Beherit has joined

  591. thomaslewis has joined

  592. thomaslewis has left

  593. thomaslewis has joined

  594. thomaslewis has left

  595. thomaslewis has joined

  596. thomaslewis has left

  597. thomaslewis has joined

  598. thomaslewis has left

  599. thomaslewis has joined

  600. rom1dep has joined

  601. thomaslewis has left

  602. thomaslewis has joined

  603. thomaslewis has left

  604. thomaslewis has joined

  605. thomaslewis has left

  606. zawarudo has left

  607. Patiga has left

  608. thomaslewis has joined

  609. thomaslewis has left

  610. thomaslewis has joined

  611. thomaslewis has left

  612. jubalh has left

  613. Kev has left

  614. Kev has joined

  615. thomaslewis has joined

  616. atomicwatch has left

  617. thomaslewis has left

  618. Vaulor has left

  619. Vaulor has joined

  620. atomicwatch has joined

  621. atomicwatch has left

  622. mh has left

  623. mh has joined

  624. atomicwatch has joined

  625. MSavoritias (fae,ve) has left

  626. atomicwatch has left

  627. thomaslewis has joined

  628. atomicwatch has joined

  629. nicoco has left

  630. Menel has left

  631. Menel has joined

  632. mh has left

  633. mh has joined

  634. thomaslewis has left

  635. Alex has left

  636. PapaTutuWawa has left

  637. jubalh has joined

  638. trần.h.trung has left

  639. trần.h.trung has joined

  640. mirux has left

  641. PapaTutuWawa has joined

  642. Vaulor has left

  643. Vaulor has joined

  644. Menel has left

  645. Beherit has left

  646. Mario Sabatino has left

  647. deuill has left

  648. Patiga has joined

  649. raghavgururajan has left

  650. Millesimus has left

  651. kurtain has joined

  652. marc0s has left

  653. marc0s has joined

  654. atomicwatch has left

  655. atomicwatch has joined

  656. Millesimus has joined

  657. debacle has joined

  658. Millesimus has left

  659. moparisthebest has left

  660. deuill has joined

  661. atomicwatch has left

  662. Millesimus has joined

  663. atomicwatch has joined

  664. Millesimus has left

  665. goffi has left

  666. thomaslewis has joined

  667. thomaslewis has left

  668. kurtain has left

  669. mh has left

  670. mh has joined

  671. Vaulor has left

  672. marc0s has left

  673. marc0s has joined

  674. Millesimus has joined

  675. atomicwatch has left

  676. mh has left

  677. atomicwatch has joined

  678. Millesimus has left

  679. mh has joined

  680. sonny has left

  681. sonny has joined

  682. thomaslewis has joined

  683. thomaslewis has left

  684. thomaslewis has joined

  685. thomaslewis has left

  686. thomaslewis has joined