button, but a click on it result in an error, while the
finish button act as expected.
My guess is that execute should be equivalent to complete when
next is not possible (but what if complete is disabled too ?).
Cheers
Goffi
encryption model, but being able to use it with
gateways or to diffuse the public key seems important to me.
Thanks
Goffi
On 31/07/2015 10:27, Daniele Ricci wrote:
Hello Goffi,
XEP-0027 has serious security concerns, especially regarding reply
attacks and key verification (you can read those in the Security
considerations paragraph of the XEP). It's true that a real
replacement hasn't been drafted yet
On 30/07/2015 11:35, Evgeny Khramtsov wrote:
Thu, 30 Jul 2015 11:07:28 +0200
Goffi go...@goffi.org wrote:
What is the point in implementing file transfer protocol which will not
work in all cases (MUC, offline, etc)? Why a developer would need
proxy65 if it's not MUC friendly? I really see
opinion). If indeed both can live together,
well, why not.
Goffi
to implement file transfer, making developers life better.
So to sum up: I rather see an xmpp: uri than an http: one to share
files with XMPP.
Goffi
On 05/05/2015 16:59, Sergey Dobrov wrote:
On 01/05/2015 21:28, Goffi wrote:
Sorry I was not replying, I'm quite busy now, but am going to join you
guys ASAP, unfortunately, got a flu now.
No worries, nice to see you back.
Yes, I am aware of the issue but it can't be fixed before we have
first).
Cheers
Goffi
On 18/04/2015 11:03, Dave Cridland wrote:
Between XEP-0355 and carbons, I think you're covered already, at first
thought.
Indeed the XEP-0355 has a mechanism to delegate MAM (or something else)
to any entity under the control of the user. The issue here is that the
data still go through the
On 03/02/2015 15:46, Dave Cridland wrote:
We can work around this in namespace delegation by adding an
attribute check in addition to namespace check, that would be better
than sending back the traffic to the server, even if it complicate the
XEP. I would still be more happy with an other
Some clients do weird stuff like encoding XHTML-IM (which is probably
not a good idea at all). Also a XEP should give some advices on what to
allow, saying that history should be disabled by default, this kind of
things.
Also there is an OTR space-based discovery system which should be
.
Goffi
on PubSub/PEP.
Thanks
Goffi
see any major issue.
/K
Cheers
Goffi
G'day Kev,
sorry for the late answer.
4.1 (roster access) would be nice to clarify that this is independent of the
roster stuff in 6121, despite looking similar (none,to,from,both).
It is related to RFC 6121, there is only none and both in addition
for managing the permission
4.2. To
On 27/01/2015 16:30, Kevin Smith wrote:
It was not blocked by Council, it’ll be published once the Editors have a
chance.
Ok great :)
I'll publish a new revision for that and also namespace delegation I
still need to some change with last feedbacks, after I'll try a prosody
implementation,
, and keep it as simple (and implementable) as possible
- once everybody agree on an ABAC system, we can re-implement a generic
system to allow external entities to access some of server privileges
Cheers
Goffi
On 17/12/2014 19:01, Goffi wrote:
On 17/12/2014 18:06, Dave Cridland wrote:
OK, I
forward, instead of
simply blocking progress.
I'm hoping too, we're putting a lot of effort to have a decent
(micro)-blogging platform on XMPP, and sometimes we have the filling to
fight against windmills.
So let me know what I can do to move forward.
Cheers
Goffi
the extra bits in their PEP
services, though; this being why I've asked Goffi specifically about
what's missing.
That's not an option for us: even if one server implements what we need,
we need a generic option which works everywhere. In addition we are
doing experimentations and we have/need a quick
an entire new thing
(and hopefully without postponing by months or years).
Goffi
things are more clear now :)
Goffi
) with
XEP-0277 compliant clients. Correct me if I'm wrong
Cheers
Goffi
service is an option generic and available quickly.
I'm curious to see some other opinions on this subject.
Cheers
Goffi
Le mardi 16 décembre 2014, 16:12:00 Dave Cridland a écrit :
Folks,
At the last Council meeting, I entered a position of -1 concerning
Privileged Entity:
http://xmpp.org
messages). OTR need to work with non XMPP gateways. It would
be really good to standardize all that...
Cheers
Goffi
attribute is good (it's capulet.lit, not
pubsub.capulet.lit), client can check it without problem.
cheers
Goffi
been granted and we can do it with a simple message stanza containing
the namespaces.
If we choose to specify namespaces in configuration, that's an option
indeed. But first it's important to specify what to do when component is
down, thank you for pointing this.
Cheers
Goffi
Regards
Goffi
Hi,
On 18/09/2014 20:19, Lance Stout wrote:
This is a relevant proposal for some stuff I'm working on, so ^5 for writing
this.
I'm glad if it seems useful :)
- It doesn't look like there is a defined way to edit or remove permissions
once granted
(at least for the client case). There
, centralized (even if git
itself is decentralized, everything else is centralized), and probably
with bad terms of use.
cheers
Goffi
On 01/09/2014 23:26, Evgeny Khramtsov wrote:
Mon, 1 Sep 2014 22:03:43 +0100
Dave Cridland d...@cridland.net wrote:
See Kurt's comment as to one possible reason why.
I use it for both work and pleasure; I'm more in the camp of wanting
to avoid a proprietary outsourced lockin for a core
On 02/09/2014 09:53, Goffi wrote:
G'day
On 01/09/2014 21:43, Dave Cridland wrote:
Not all our contributors currently will use github.
Yes that's my case: I haven't a github account, and I definitely don't
want one. Actually I think it would be a shame to use that for XMPP as
it is the exact
is not neutral, and there is not only one way to make think
simple (and it's actually more simple and easy to use email than to
force people to create an account to a service).
Goffi
(http://salut-a-toi.org), made in python. If
anybody is interested, we can have a short talk about the project and
make a demo.
cheers
Goffi
On 23/07/2014 17:53, Sergey Dobrov wrote:
Hello folks,
We are wondering if anyone would be interested in autumn summit if we'd
move it from North
G'day,
On 24/07/2014 20:47, Adrien wrote:
Western or central Europe would be easier for me... can't suggest a
place though.
Same thing for me, I would try to attend a summit if it is in western or
central Europe (specially Prague, Wien or Paris).
Cheers
Goffi (Salut à Toi project)
active these days.
If teams of different projects can meet up, maybe we can manage something.
Cheers
Goffi (Salut à Toi project)
because you may want to delegate a namespace (e.g. vcard-temp) without
giving privileged access, it's an other thing.
Cheers
Goffi
Le 2014-05-15 10:44, Steven Lloyd Watkin a écrit :
Id see this as a separate XEP myself since were talking about two
essentially different use cases (although Id assume theyd often be
used in parallel).
I'm planing to work on a separate « namespace delegation » XEP for this
reason.
Ive
Le 2014-05-15 22:24, Dave Cridland a écrit :
Furhtermore, Binary suggested to use permission even in admin mode
(without user confirmation in this case): a server may want to only
allow jabber:iq:roster get to a component. We can use this phase
to aknowledge the component of which permissions
if the component want to request directly the client, but indeed a full jid is
needed in the case of an IQ to the client, so it's probably a good idea to
remove the privilege/ element...
Cheers
Goffi
Le vendredi 9 mai 2014, 20:52:42 Goffi a écrit :
I forgot to mention: the permission mechanism is largely
Le jeudi 8 mai 2014, 10:45:02 Dave Cridland a écrit :
Trapping namespaces on IQ seems relatively easy to implement. Trapping
namespaces on messages and presence, though, seems harder, because you need
to decide if the stanza is forked or if the component processes exclusively.
Your right.
://repos.goffi.org/sat_docs/file/677de998f9d9/xmpp/xep-proto-privileged-component.xml
.
Feedbacks more than welcome.
Cheers
Goffi
done things badly,
You can find the html version on
http://www.goffi.org/public/xmpp/xep/xep-proto-privileged-component.html,
and the XML on
http://repos.goffi.org/sat_docs/file/677de998f9d9/xmpp/xep-proto-privileged
-component.xml .
Feedbacks more than welcome.
Cheers
Goffi
to work on protoxep for this now, anybody interested in the
subject please manifest yourself :)
Cheers
Goffi
Le mercredi 13 novembre 2013, 18:35:45 Matthew Wild a écrit :
On 13 November 2013 18:12, Goffi go...@goffi.org wrote:
So, is it possible to remove these restrictions from the XEP
to switch server, or to try
experimental implementation in our favorite language.
So, is it possible to remove these restrictions from the XEP ? Or at
least to have an unsecure mode, and a secure mode with full access to
roster ?
Cheers
Goffi
- what about anonymous comments ?
Anyway, we should definitely avoid 2 XEPs for comments.
I wander if I'm missing something, so if anybody has tried an
implementation of the XEP-0303 and/or XEP-0277, please give feedbacks.
Cheers
Goffi
G'day,
I just realised that you answered my question later !
Any news on that ? Did the initial author finally answered ?
Where is your rewritten XEP available ?
Cheers
Goffi
Le vendredi 7 décembre 2012 17:46:40 Sergey Dobrov a écrit :
There was no response to my letter so I rewrote the XEP
Ok, because I have some comments on the proto-xep, so I'm waiting for the
feedback.
thanks
Le mardi 5 mars 2013 16:34:43 Sergey Dobrov a écrit :
On 03/05/2013 04:17 PM, Goffi wrote:
G'day,
Hello,
I just realised that you answered my question later !
Any news on that ? Did
.
Cheers
Goffi
Le mardi 29 mai 2012 09:35:10 Peter Saint-Andre a écrit :
I'm not a big fan of invisibility, but if we're going to do it then we
might as well do it right.
Some clients and servers use XEP-0018, but it violates the core XMPP
specs, which seems like a bad idea.
Some clients
Le 29/05/2012 19:01, Peter Saint-Andre a écrit :
So it sounds as if you're a target user for privacy lists. :) I'm not
necessarily interested in forbidding or deprecating privacy lists, but
in general I think they're complicated and that invisiblity and
blocking are the most common use cases,
this XEP and put the
experimental status ? Is anybody working on something similar ?
Thanks
Goffi
PS: sent a copy of this to the author of the XEP, and the standard@
mailing list.
I'm implementing this one first.
Any suggestion welcome
thanks
Goffi
attention,
specially in server side: it's important to have permission management easy
for the end-user.
Cheers
Jérôme Poisson (aka Goffi)
PS: I have also worked on features for my client that I'd like to standardize,
like a generic card games management.
Le Jeudi 18 Août 2011 19:29:21, Sergey Dobrov a écrit :
first, here are my main needs for microblogging:
- the possibility to have several nodes with different access models,
and for a user to subscribe to them automatically
Could you give some example usecases for that? Since I don't
Le Jeudi 18 Août 2011 20:40:05, Sergey Dobrov a écrit :
It's a bad idea to append the number to the namespace since it reserved
for different revisions of XEP and not for your purpose. Again, I think
that this should be solved by some privacy lists extension since your
decision again
201 - 254 of 254 matches
Mail list logo
